linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: mel@skynet.ie (Mel Gorman)
To: Christoph Lameter <clameter@sgi.com>
Cc: Nick Piggin <npiggin@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	kenchen@google.com, jschopp@austin.ibm.com, apw@shadowen.org,
	kamezawa.hiroyu@jp.fujitsu.com, a.p.zijlstra@chello.nl,
	y-goto@jp.fujitsu.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: -mm merge plans -- anti-fragmentation
Date: Wed, 11 Jul 2007 10:48:38 +0100	[thread overview]
Message-ID: <20070711094838.GD7568@skynet.ie> (raw)
In-Reply-To: <Pine.LNX.4.64.0707101142340.11906@schroedinger.engr.sgi.com>

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-07-11  9:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-10 10:20 Mel Gorman
2007-07-10 11:01 ` KAMEZAWA Hiroyuki
2007-07-10 11:12   ` Mel Gorman
2007-07-10 11:38     ` KAMEZAWA Hiroyuki
2007-07-10 15:50       ` Mel Gorman
2007-07-10 11:04 ` Peter Zijlstra
2007-07-10 13:24   ` Mel Gorman
2007-07-10 13:03 ` Nick Piggin
2007-07-10 13:55   ` Mel Gorman
2007-07-10 18:47     ` Christoph Lameter
2007-07-10 18:46   ` Christoph Lameter
2007-07-11  9:48     ` Mel Gorman [this message]
2007-07-10 14:29 ` Dave McCracken
2007-07-10 15:23   ` Nick Piggin
2007-07-10 17:11     ` Dave McCracken
2007-07-11  2:59       ` Nick Piggin
2007-07-11 10:01         ` Mel Gorman
2007-07-11 13:03         ` Andy Whitcroft
2007-07-11  8:55       ` Christoph Hellwig
2007-07-10 18:50     ` Christoph Lameter
2007-07-11 10:05       ` Mel Gorman
2007-07-12 19:29 ` Andrew Morton
2007-07-12 21:32   ` Mel Gorman
2007-07-13 15:56     ` [PATCH] Add a movablecore= parameter for sizing ZONE_MOVABLE Mel Gorman
2007-07-14  8:28       ` Nick Piggin
2007-07-14 13:02         ` Mel Gorman
2007-07-15 13:47           ` KAMEZAWA Hiroyuki
2007-07-13 10:20   ` -mm merge plans -- anti-fragmentation Andy Whitcroft
2007-07-13 16:58     ` Christoph Lameter
2007-07-13 17:02     ` Nish Aravamudan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070711094838.GD7568@skynet.ie \
    --to=mel@skynet.ie \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=apw@shadowen.org \
    --cc=clameter@sgi.com \
    --cc=jschopp@austin.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kenchen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=y-goto@jp.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox