linux-kernel - Re: [patch 4/5] mm: writeback: throttle __GFP

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]

Message-ID: <20110725203705.GA21691@tassilo.jf.intel.com>
Date:	Mon, 25 Jul 2011 13:37:05 -0700
From:	Andi Kleen <ak@...ux.intel.com>
To:	Johannes Weiner <jweiner@...hat.com>
Cc:	linux-mm@...ck.org, Dave Chinner <david@...morbit.com>,
	Christoph Hellwig <hch@...radead.org>,
	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Rik van Riel <riel@...hat.com>,
	Minchan Kim <minchan.kim@...il.com>, Jan Kara <jack@...e.cz>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 4/5] mm: writeback: throttle __GFP_WRITE on per-zone
 dirty limits

> The global dirty limits are put in proportion to the respective zone's
> amount of dirtyable memory and the allocation denied when the limit of
> that zone is reached.
> 
> Before the allocation fails, the allocator slowpath has a stage before
> compaction and reclaim, where the flusher threads are kicked and the
> allocator ultimately has to wait for writeback if still none of the
> zones has become eligible for allocation again in the meantime.
> 

I don't really like this. It seems wrong to make memory
placement depend on dirtyness.

Just try to explain it to some system administrator or tuner: her 
head will explode and for good reasons.

On the other hand I like doing round-robin in filemap by default
(I think that is what your patch essentially does)
We should have made  this default long ago. It avoids most of the
"IO fills up local node" problems people run into all the time.

So I would rather just change the default in filemap allocation.

That's also easy to explain.

BTW the original argument why this wasn't done was that it may
be a problem on extremly large systems, but I think it's reasonable
to let these oddballs change their defaults instead of letting
everyone else handle them.

-Andi
--
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/