All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arthur Marsh <arthur.marsh@internode.on.net>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Clemens Ladisch <cladisch@googlemail.com>,
	alsa-user@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [Alsa-user] new source of MIDI playback slow-down identified - 5a03b051ed87e72b959f32a86054e1142ac4cf55 thp: use compaction in kswapd for GFP_ATOMIC order > 0
Date: Sun, 27 Feb 2011 19:18:00 +1030	[thread overview]
Message-ID: <4D6A0FC0.1000307@internode.on.net> (raw)
In-Reply-To: <20110226064339.GC19630@random.random>



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.

  reply	other threads:[~2011-02-27  8:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <g0ia38-jj6.ln1@ppp121-45-136-118.lns11.adl6.internode.on.net>
2011-02-22  7:37 ` [Alsa-user] new source of MIDI playback slow-down identified - 5a03b051ed87e72b959f32a86054e1142ac4cf55 thp: use compaction in kswapd for GFP_ATOMIC order > 0 Clemens Ladisch
2011-02-22  7:46   ` Arthur Marsh
2011-02-22 13:40   ` Andrea Arcangeli
2011-02-22 16:15     ` Andrea Arcangeli
2011-02-22 16:59       ` Mel Gorman
2011-02-22 17:08         ` Andrea Arcangeli
2011-02-22 17:37           ` Mel Gorman
2011-02-22 17:47       ` Arthur Marsh
2011-02-22 19:43         ` Andrea Arcangeli
2011-02-23  9:15           ` Mel Gorman
2011-02-23 11:41             ` Arthur Marsh
2011-02-23 13:50               ` Clemens Ladisch
2011-02-23 17:01               ` Mel Gorman
2011-02-23 17:40                 ` Andrea Arcangeli
2011-02-23 16:24         ` Andrea Arcangeli
2011-02-23 16:36           ` Andrea Arcangeli
2011-02-23 16:40             ` Andrea Arcangeli
2011-02-23 16:47               ` Andrea Arcangeli
2011-02-23 16:55           ` Andrea Arcangeli
2011-02-23 20:07             ` Arthur Marsh
2011-02-23 21:25               ` Andrea Arcangeli
2011-02-23 21:55                 ` Arthur Marsh
2011-02-23 23:59                   ` Andrea Arcangeli
2011-02-24  1:40                     ` Arthur Marsh
2011-02-24  1:54                       ` Andrea Arcangeli
2011-02-26  6:43                         ` Andrea Arcangeli
2011-02-27  8:48                           ` Arthur Marsh [this message]
2011-02-23 17:10           ` Mel Gorman
2011-02-23 17:27             ` Andrea Arcangeli
2011-02-23 17:44               ` Mel Gorman
2011-02-23 18:14                 ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D6A0FC0.1000307@internode.on.net \
    --to=arthur.marsh@internode.on.net \
    --cc=aarcange@redhat.com \
    --cc=alsa-user@lists.sourceforge.net \
    --cc=cladisch@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.