Re: [Alsa-user] new source of MIDI playback slow-down identified- 5a03b051ed87e72b959f32a86054e1142ac4cf55 thp: use compaction in kswapdfor GFP_ATOMIC order > 0

[Arthur Marsh]

Andrea Arcangeli wrote, on 24/02/11 03:25:
> On Wed, Feb 23, 2011 at 05:24:32PM +0100, Andrea Arcangeli wrote:
> > On Wed, Feb 23, 2011 at 04:17:44AM +1030, Arthur Marsh wrote:
> > > OK, these patches applied together against upstream didn't cause a crash
> > > but I did observe:
> > >
> > > significant slowdowns of MIDI playback (moreso than in previous cases,
> > > and with less than 20 Meg of swap file in use);
> > >
> > > kswapd0 sharing equal top place in CPU usage at times (e.g. 20 percent).
> > >
> > > If I should try only one of the patches or something else entirely,
> > > please let me know.
> >
> > Yes, with irq off, schedule won't run and need_resched won't get set.
> >
> > So let's try this.
> >
> > In case this doesn't fix I definitely give it up with compaction in
> > kswapd as GFP_ATOMIC will likely not get an huge benefit out of
> > compaction anyway because 1) the allocations from GFP_ATOMIC are
> > likely short lived, 2) the cost of the compaction scan loop +
> > migration may be higher than the benefit we get from jumbo frames
> >
> > So if this doesn't fix it, I'll already post a definitive fix that
> > removes compaction from kswapd (but leaves it enabled for direct
> > reclaim for all order sizes including kernel stack). I already
> > verified that this solves not just the midi latency issue but the
> > other server benchmark that I'm dealing with. Then we can think at
> > compaction+kswapd later for 2.6.39 but I think we need to close this
> > kswapd issue in time for 2.6.38. So if the below isn't enough the next
> > patch should be applied. I'll get those two patches tested in the
> > server load too, and I'll let you know how the results are when it
> > finishes.
> >
> > Please apply also the attached "kswapd-high-wmark" before the below
> > one.
> > +		if (need_resched() || spin_is_contended(&zone->lru_lock)) {
> > +			if (fatal_signal_pending(current))
> > +				break;
>
> this is compaction-kswapd-2, to fix the buglet same as in the other
> patch.
>
> In short (to avoid confusion) it'll be helpful if you can test
> compaction-kswapd-2 vs compaction-no-kswapd-3 and let us know if both
> are ok or if only compaction-no-kswapd-3 is ok. compaction-no-kswapd-3
> should help, compaction-kswapd-2 I'm unsure. And as usual I suggest to
> apply kswapd-high-wmark (attached to previous emails) _before_
> applying both patches.

kswapd-high_wmark + compaction-kswapd-2 - kswapd0 CPU up to 11 percent 
and slightly less pronounced slowdowns of MIDI playback compared to 
previous patches.

kswapd-high_wmark + compaction-no-kswapd-3 - kswapd0 CPU up to 2.3 
percent and no noticable slowdown of MIDI playback.

Mel Gorman's mm/compaction.c patch - kswapd0 CPU up to 20 percent and no 
noticable slowdown of MIDI playback.

Thanks everyone for the help with this.

Arthur.
--
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/