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 26/02/11 17:13:
> On Thu, Feb 24, 2011 at 02:54:05AM +0100, Andrea Arcangeli wrote:
> > Ok so tomorrow I'll get all results on these 3 kernels (
> > compaction-kswapd-3+compaction_alloc_lowlat-2 vs
> > compaction-no-kswapd-3+compaction_alloc_lowlat-2 vs
> > compaction_alloc_lowlat2) on network server load, where throughout is
> > measured in addition to latency. Then we'll have a better picture to
>
> Latency is still lowest with compaction-no-kswapd-3. compaction_alloc
> still is at the top of the profiling with
> compaction-kswapd-3+compaction_alloc_lowlat-2. However
> compaction-kswapd-3 reduced the overhead somewhat but not enough to be
> as fast as with compaction-no-kswapd-3 (even if much better than
> before).
>
> So we should apply compaction-no-kswapd-3 to 2.6.38 I think.

I built a kernel based against git head of around 0800 UTC Saturday 
2011-02-26 plus compaction-no-kswapd-3 (Andrea's) and 
compaction_alloc_lowlat-2 (Mel's) patches.

The the latency performance for MIDI playback is excellent and kswap0 
has reported 100 seconds of CPU time in 22 hours of the kernel kernel 
running.

However, I am now battling against the kernel freeing up memory when 
using icedove/thunderbird. top is reporting 74 MiB resident, 418 MiB 
virtual, and as I pause typing to watch top output, free RAM has gone up 
to 50 MiB and I'm stuck waiting for parts of icedove to swap back in so 
that I can get a response from my input (either scrolling a message when 
reading it or composing a message, where I am left waiting for the text 
that I typed to appear).

Normally in this machine with only 384 MiB RAM and (say) 2.6.35-2.6.37 
kernels, free RAM will hover around the 5 MiB mark when lots of 
applications are open. I may wait when switching from one running 
application to another for it to respond, but once I am using that 
particular application it sufficiently responsive not to be annoying.

The aggressive reclamation of RAM by the kernel I built around 0800 UTC 
Saturday is working against the application currently in focus.

I will try Andrea's and Mel's patches built against 2.6.36-rc6 over the 
next several hours to see how that compares.

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/