Re: [PATCH 3/3] mm: slub: Default slub_max_order to 0

[Johannes Weiner]

On Thu, May 12, 2011 at 03:04:12PM -0500, James Bottomley wrote:
> On Thu, 2011-05-12 at 14:44 -0500, James Bottomley wrote:
> > On Thu, 2011-05-12 at 13:37 -0500, James Bottomley wrote:
> > > On Thu, 2011-05-12 at 18:55 +0300, Pekka Enberg wrote:
> > > > On Thu, 2011-05-12 at 10:43 -0500, James Bottomley wrote:
> > > > > However, since you admit even you see problems, let's concentrate on
> > > > > fixing them rather than recriminations?
> > > > 
> > > > Yes, please. So does dropping max_order to 1 help?
> > > > PAGE_ALLOC_COSTLY_ORDER is set to 3 in 2.6.39-rc7.
> > > 
> > > Just booting with max_slab_order=1 (and none of the other patches
> > > applied) I can still get the machine to go into kswapd at 99%, so it
> > > doesn't seem to make much of a difference.
> > > 
> > > Do you want me to try with the other two patches and max_slab_order=1?
> > 
> > OK, so patches 1 + 2 plus setting slub_max_order=1 still manages to
> > trigger the problem (kswapd spinning at 99%).  This is still with
> > PREEMPT; it's possible that non-PREEMPT might be better, so I'll try
> > patches 1+2+3 with PREEMPT just to see if the perturbation is caused by
> > it.
> 
> Confirmed, I'm afraid ... I can trigger the problem with all three
> patches under PREEMPT.  It's not a hang this time, it's just kswapd
> taking 100% system time on 1 CPU and it won't calm down after I unload
> the system.

That is kind of expected, though.  If one CPU is busy with a streaming
IO load generating new pages, kswapd is busy reclaiming the old ones
so that the generator does not have to do the reclaim itself.

By unload, do you mean stopping the generator?  And if so, how quickly
after you stop the generator does kswapd go back to sleep?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/