The slab reaper takes global locks. If one makes all cache reapers fire at the same time as this patch does then there will be a lot of contention that may result lots of interrupt holdoffs since some locks are taken with interrupts disabled. The vm statistics counters are updated and will content for global cachelines if this is done.
The approach is fine up to 2 cpus. With 2 cpus we can schedule one cache reaper on each cpu each second. So I guess that this was not noticed. For 16 cpus we are already scheduling 8 parallel cache reapers every second. In a 512 cpu system desaster strikes with 256 cache reapers being fired off at the same time each second Git commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b2842146cb4105877c2be51d3857ec61ebd4ff9 This is in 2.6.20 / 2.6.21. I'd suggest to use a staggered per cpu approach instead that runs multiple per cpu timers at once. But every batch of these timers must be run at an offset from each other. Not at the same time please. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/