[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110516084514.GD5279@suse.de>
Date: Mon, 16 May 2011 09:45:14 +0100
From: Mel Gorman <mgorman@...e.de>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: akpm@...ux-foundation.org, James.Bottomley@...senPartnership.com,
colin.king@...onical.com, raghu.prabhu13@...il.com, jack@...e.cz,
chris.mason@...cle.com, cl@...ux.com, penberg@...nel.org,
riel@...hat.com, hannes@...xchg.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 4/4] mm: vmscan: If kswapd has been running too long,
allow it to sleep
On Sun, May 15, 2011 at 07:27:12PM +0900, KOSAKI Motohiro wrote:
> (2011/05/13 23:03), Mel Gorman wrote:
> > Under constant allocation pressure, kswapd can be in the situation where
> > sleeping_prematurely() will always return true even if kswapd has been
> > running a long time. Check if kswapd needs to be scheduled.
> >
> > Signed-off-by: Mel Gorman<mgorman@...e.de>
> > ---
> > mm/vmscan.c | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index af24d1e..4d24828 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -2251,6 +2251,10 @@ static bool sleeping_prematurely(pg_data_t *pgdat, int order, long remaining,
> > unsigned long balanced = 0;
> > bool all_zones_ok = true;
> >
> > + /* If kswapd has been running too long, just sleep */
> > + if (need_resched())
> > + return false;
> > +
>
> Hmm... I don't like this patch so much. because this code does
>
> - don't sleep if kswapd got context switch at shrink_inactive_list
> - sleep if kswapd didn't
>
> It seems to be semi random behavior.
>
It's possible to keep kswapd awake simply by allocating fast enough that
the watermarks are never balanced making kswapd appear to consume 100%
of CPU. This check causes kswapd to sleep in this case. The processes
doing the allocations will enter direct reclaim and probably stall while
processes that are not allocating will get some CPU time.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists