From: mel@skynet.ie (Mel Gorman)
Subject: Re: [00/41] Large Blocksize Support V7 (adds memmap support)
Date: Sun, 16 Sep 2007 22:31:55 +0100
Message-ID: <20070916213154.GG16406@skynet.ie>
References: <20070911060349.993975297@sgi.com> <200709110452.20363.nickpiggin@yahoo.com.au> <20070911121225.GE13132@lazybastard.org> <20070915014449.4f9cdb51.akpm@linux-foundation.org> <20070916175352.GB2393@lazybastard.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Christoph Lameter <clameter@sgi.com>, andrea@suse.de,
	torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	William Lee Irwin III <wli@holomorphy.com>,
	David Chinner <dgc@sgi.com>,
	Jens Axboe <jens.axboe@oracle.com>,
	Badari Pulavarty <pbadari@gmail.com>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	Fengguang Wu <fengguang.wu@gmail.com>,
	swin wang <wangswin@gmail.com>, totty.lu@gmail.com,
	hugh@veritas.com
To: J?rn Engel <joern@logfs.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from gir.skynet.ie ([193.1.99.77]:55587 "EHLO gir.skynet.ie"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752164AbXIPVb6 (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Sun, 16 Sep 2007 17:31:58 -0400
Content-Disposition: inline
In-Reply-To: <20070916175352.GB2393@lazybastard.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On (16/09/07 19:53), J?rn Engel didst pronounce:
> On Sat, 15 September 2007 01:44:49 -0700, Andrew Morton wrote:
> > On Tue, 11 Sep 2007 14:12:26 +0200 J=F6rn Engel <joern@logfs.org> w=
rote:
> >=20
> > > While I agree with your concern, those numbers are quite silly.  =
The
> > > chances of 99.8% of pages being free and the remaining 0.2% being
> > > perfectly spread across all 2MB large_pages are lower than those =
of SHA1
> > > creating a collision.
> >=20
> > Actually it'd be pretty easy to craft an application which allocate=
s seven
> > pages for pagecache, then one for <something>, then seven for pagec=
ache, then
> > one for <something>, etc.
> >=20
> > I've had test apps which do that sort of thing accidentally.  The r=
esult
> > wasn't pretty.
>=20
> I bet!  My (false) assumption was the same as Goswin's.  If non-movab=
le
> pages are clearly seperated from movable ones and will evict movable
> ones before polluting further mixed superpages, Nick's scenario would=
 be
> nearly infinitely impossible.
>=20

It would be plain impossible from a fragmentation point-of-view but you
meet interesting situations when a GFP_NOFS allocation has no kernel bl=
ocks
available to use. It can't reclaim, maybe it can move but not with curr=
ent
code (it should be able to with the Memory Compaction patches).

> Assumption doesn't reflect current code.  Enforcing this assumption
> would cost extra overhead.  The amount of effort to make Christoph's
> approach work reliably seems substantial and I have no idea whether i=
t
> would be worth it.
>=20

Current code doesn't reflect your assumptions simply because the costs =
are so
high. We'd need to be really sure it's worth it and if the answer is "y=
es",
then we are looking at Andrea's approach (more likely) or I can check o=
ut
evicting blocks of 16KB, 64KB or whatever the large block is.

--=20
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-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html