linux-kernel - Re: [PATCH 9/9] writeback: Prioritise dirty inodes encountered by reclaim for background flushing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Jul 2010 12:30:26 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, Dave Chinner <david@...morbit.com>,
	Chris Mason <chris.mason@...cle.com>,
	Nick Piggin <npiggin@...e.de>, Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [PATCH 9/9] writeback: Prioritise dirty inodes encountered by
	reclaim for background flushing

On Wed, Jul 28, 2010 at 07:08:07AM -0400, Christoph Hellwig wrote:
> On Wed, Jul 28, 2010 at 11:27:23AM +0100, Mel Gorman wrote:
> > It is preferable that as few dirty pages are dispatched for cleaning from
> > the page reclaim path. When dirty pages are encountered by page reclaim,
> > this patch marks the inodes that they should be dispatched immediately. When
> > the background flusher runs, it moves such inodes immediately to the dispatch
> > queue regardless of inode age.
> 
> Thus whole thing looks rather hacky to me.  Does it really give a large
> enough benefit to be worth all the hacks?
> 

Not enough benefit in enough situations - at least based on my tests but
it's possible my systems are just not large enough to detect anything.
The figures in the leader show that the patch does reduce the number of dirty
pages encountered by page reclaim in many cases but only in one instance,
PPC64 running sysbench, was it a really big difference.

I included this patch because Wu suggested that that page reclaim
waking threads to clean X pages depends on luck to get the right pages.
He suggested prioritising inodes with known dirty LRU pages and this was a
first prototype. It only takes inodes into account and the figures didn't
really hold up on the hardware I was using. He suggested ways that page
offset could be taken into account with some invasiveness so I'm inclined
to drop this patch for now because better ideas exist.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/