On Thu, 12 May 2011, James Bottomley wrote: > > > */ > > > static int slub_min_order; > > > -static int slub_max_order = PAGE_ALLOC_COSTLY_ORDER; > > > +static int slub_max_order; > > > > If we really need to do this then do not push this down to zero please. > > SLAB uses order 1 for the meax. Lets at least keep it theere. > > 1 is the current value. Reducing it to zero seems to fix the kswapd > induced hangs. The problem does look to be some shrinker/allocator > interference somewhere in vmscan.c, but the fact is that it's triggered > by SLUB and not SLAB. I really think that what's happening is some type > of feedback loops where one of the shrinkers is issuing a > wakeup_kswapd() so kswapd never sleeps (and never relinquishes the CPU > on non-preempt). The current value is PAGE_ALLOC_COSTLY_ORDER which is 3. > > We have been using SLUB for a long time. Why is this issue arising now? > > Due to compaction etc making reclaim less efficient? > > This is the snark argument (I've said it thrice the bellman cried and > what I tell you three times is true). The fact is that no enterprise > distribution at all uses SLUB. It's only recently that the desktop > distributions started to ... the bugs are showing up under FC15 beta, > which is the first fedora distribution to enable it. I'd say we're only > just beginning widespread SLUB testing. Debian and Ubuntu have been using SLUB for a long time (and AFAICT from my archives so has Fedora). I have been running those here for a couple of years and the issues that I see here seem to be only with the most recent kernels that now do compaction and other reclaim tricks. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
