[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100415093214.GV2493@dastard>
Date: Thu, 15 Apr 2010 19:32:14 +1000
From: Dave Chinner <david@...morbit.com>
To: Suleiman Souhlal <ssouhlal@...ebsd.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Mel Gorman <mel@....ul.ie>,
Chris Mason <chris.mason@...cle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, suleiman@...gle.com
Subject: Re: [PATCH 1/4] vmscan: delegate pageout io to flusher thread if
current is kswapd
On Thu, Apr 15, 2010 at 01:05:57AM -0700, Suleiman Souhlal wrote:
>
> On Apr 14, 2010, at 9:11 PM, KOSAKI Motohiro wrote:
>
> >Now, vmscan pageout() is one of IO throuput degression source.
> >Some IO workload makes very much order-0 allocation and reclaim
> >and pageout's 4K IOs are making annoying lots seeks.
> >
> >At least, kswapd can avoid such pageout() because kswapd don't
> >need to consider OOM-Killer situation. that's no risk.
> >
> >Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
>
> What's your opinion on trying to cluster the writes done by pageout,
> instead of not doing any paging out in kswapd?
XFS already does this in ->writepage to try to minimise the impact
of the way pageout issues IO. It helps, but it is still not as good
as having all the writeback come from the flusher threads because
it's still pretty much random IO.
And, FWIW, it doesn't solve the stack usage problems, either. In
fact, it will make them worse as write_one_page() puts another
struct writeback_control on the stack...
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
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