All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: akpm@osdl.org
Cc: Christoph Lameter <clameter@sgi.com>, Mel Gorman <mel@csn.ul.ie>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Date: Wed, 2 Feb 2005 14:49:36 -0200	[thread overview]
Message-ID: <20050202164936.GA23718@logos.cnet> (raw)
In-Reply-To: <Pine.LNX.4.58.0502020026040.16992@skynet>


Hi Andrew,

What are your thoughts about inclusion of Mel's allocator work on -mm ?

On Wed, Feb 02, 2005 at 12:31:36AM +0000, Mel Gorman wrote:
> On Tue, 1 Feb 2005, Christoph Lameter wrote:
> 
> > On Tue, 1 Feb 2005, Mel Gorman wrote:
> >
> > > > Would it not be better to zero the global 2^MAX_ORDER pages by the scrub
> > > > daemon and have a global zeroed page list? That way you may avoid zeroing
> > > > when splitting pages?
> > > >
> > >
> > > Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon
> > > is going to be doing nothing which is why I think it needs to look at the
> > > free pages of lower orders.
> > >
> > > That is solveable though in one of two ways. One, the scrub daemon can
> > > zero pages from the global list and then add them to the USERZERO pool. It
> > > has the advantage of requiring no more memory and is simple. The second is
> > > to create a second global list. However, I think it only makes sense to
> > > have this as part of the scrub daemon patch (I can write it if thats a
> > > problem) rather than a standalone patch from me.
> >
> > Approach one is fine and I will do an update the remaining prezero patches
> > to do just that.
> 
> There is another problem with approach one. Assuming all 2^MAX_ORDER pages
> have been zeroed and in USERZERO pool and there are no other free pages,
> an allocation for the USERRCLM pool would search all the other pools
> before finding the zerod pages. This could really slow things up but it is
> not a problem approach two suffers from.
> 
> > When will your patches be in Linus tree? ;-)
> >
> 
> Your guess is as good as mine :) . I am fairly sure the allocator is
> somewhere in Andrew's list of patches to look at to consider for inclusion
> into -mm so I suppose it'll get a spin in that tree when he feels it's
> ready.

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: akpm@osdl.org
Cc: Christoph Lameter <clameter@sgi.com>, Mel Gorman <mel@csn.ul.ie>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Date: Wed, 2 Feb 2005 14:49:36 -0200	[thread overview]
Message-ID: <20050202164936.GA23718@logos.cnet> (raw)
In-Reply-To: <Pine.LNX.4.58.0502020026040.16992@skynet>

Hi Andrew,

What are your thoughts about inclusion of Mel's allocator work on -mm ?

On Wed, Feb 02, 2005 at 12:31:36AM +0000, Mel Gorman wrote:
> On Tue, 1 Feb 2005, Christoph Lameter wrote:
> 
> > On Tue, 1 Feb 2005, Mel Gorman wrote:
> >
> > > > Would it not be better to zero the global 2^MAX_ORDER pages by the scrub
> > > > daemon and have a global zeroed page list? That way you may avoid zeroing
> > > > when splitting pages?
> > > >
> > >
> > > Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon
> > > is going to be doing nothing which is why I think it needs to look at the
> > > free pages of lower orders.
> > >
> > > That is solveable though in one of two ways. One, the scrub daemon can
> > > zero pages from the global list and then add them to the USERZERO pool. It
> > > has the advantage of requiring no more memory and is simple. The second is
> > > to create a second global list. However, I think it only makes sense to
> > > have this as part of the scrub daemon patch (I can write it if thats a
> > > problem) rather than a standalone patch from me.
> >
> > Approach one is fine and I will do an update the remaining prezero patches
> > to do just that.
> 
> There is another problem with approach one. Assuming all 2^MAX_ORDER pages
> have been zeroed and in USERZERO pool and there are no other free pages,
> an allocation for the USERRCLM pool would search all the other pools
> before finding the zerod pages. This could really slow things up but it is
> not a problem approach two suffers from.
> 
> > When will your patches be in Linus tree? ;-)
> >
> 
> Your guess is as good as mine :) . I am fairly sure the allocator is
> somewhere in Andrew's list of patches to look at to consider for inclusion
> into -mm so I suppose it'll get a spin in that tree when he feels it's
> ready.
--
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:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2005-02-02 20:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-01 17:16 [PATCH 2/2] Helping prezoring with reduced fragmentation allocation Mel Gorman
2005-02-01 17:16 ` Mel Gorman
2005-02-01 19:18 ` Christoph Lameter
2005-02-01 19:18   ` Christoph Lameter
2005-02-01 21:06   ` Mel Gorman
2005-02-01 21:06     ` Mel Gorman
2005-02-02  0:05     ` Christoph Lameter
2005-02-02  0:05       ` Christoph Lameter
2005-02-02  0:31       ` Mel Gorman
2005-02-02  0:31         ` Mel Gorman
2005-02-02 16:49         ` Marcelo Tosatti [this message]
2005-02-02 16:49           ` Marcelo Tosatti
2005-02-02 20:19           ` Andrew Morton
2005-02-02 20:19             ` Andrew Morton
2005-02-02 22:03             ` Christoph Lameter
2005-02-02 22:03               ` Christoph Lameter

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=20050202164936.GA23718@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.