linux-kernel - Re: -mm merge plans -- anti-fragmentation

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, 11 Jul 2007 10:48:38 +0100
From:	mel@...net.ie (Mel Gorman)
To:	Christoph Lameter <clameter@....com>
Cc:	Nick Piggin <npiggin@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>, kenchen@...gle.com,
	jschopp@...tin.ibm.com, apw@...dowen.org,
	kamezawa.hiroyu@...fujitsu.com, a.p.zijlstra@...llo.nl,
	y-goto@...fujitsu.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: -mm merge plans -- anti-fragmentation

On (10/07/07 11:46), Christoph Lameter didst pronounce:
> On Tue, 10 Jul 2007, Nick Piggin wrote:
> 
> > I realise in your pragmatic approach, you are encouraging users to
> > put fallbacks in place in case a higher order page cannot be allocated,
> > but I don't think either higher order pagecache or higher order slubs
> > have such fallbacks (fsblock or a combination of fsblock and higher
> > order pagecache could have, but...).
> 
> We have run mm kernels for month now without the need of a fallback. I 
> purpose of ZONE_MOVABLE was to guarantee that higher order pages could be 
> reclaimed and thus make the scheme reliable?
> 

That and they would be available within a specified limit. With grouping
pages by mobility, high order pages will be available but it's workload
dependant on how many there will be. This sort of predictability is
important for hugepages and memory unplug although it's of less
relevance to order-3 and order-4 users.

> The experience so far shows that the approach works reliably. If there are 
> issues then they need to be fixed. Putting in workarounds in other places 
> such as in fsblock may just be hiding problems if there are any.

I think fsblock as it stands would gain from grouping pages by mobility.
It could use high order pages where they were available and fallback to
using the slower vmap approach when they weren't. I don't see why
highorder page cache and fsblock would be mutually exclusive. For that
matter, I don't see why any of these approachs are mutually exclusive
with what Andrea is doing other than having more than one way of
skinning a cat in the kernal at the same time might be confusing.

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