linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Matthew Dobson <colpatch@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, Sridhar Samudrala <sri@us.ibm.com>,
	pavel@suse.cz, Andrew Morton <akpm@osdl.org>,
	Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH 1/6] Create Critical Page Pool
Date: Wed, 14 Dec 2005 11:48:39 +0100	[thread overview]
Message-ID: <20051214104839.GJ23878@opteron.random> (raw)
In-Reply-To: <439FCF4E.3090202@us.ibm.com>

Hi Matthew,

On Tue, Dec 13, 2005 at 11:52:46PM -0800, Matthew Dobson wrote:
> Create the basic Critical Page Pool.  Any allocation specifying
> __GFP_CRITICAL will, as a last resort before failing the allocation, try to
> get a page from the critical pool.  For now, only singleton (order 0) pages
> are supported.

Hmm sorry, but this design looks wrong to me. Since the caller has to
use __GFP_CRITICAL anyway, why don't you build this critical pool
_outside_ the page allocator exactly like the mempool does?

Then you will also get an huge advantage, that is allowing to create
more than one critical pool without having to add a __GFP_CRITICAL2 next
month.

So IMHO if something you should create something like a mempool (if the
mempool isn't good enough already for your usage), so more subsystems
can register their critical pools. Call it criticalpool.c or similar but
I wouldn't mess with __GFP_* and page_alloc.c, and the sysctl should be
in the user subsystem, not global.

Or perhaps you can share the mempool code and extend the mempool API to
refill itself internally automatically as soon as pages are being
released.

You may still need a single hook in the __free_pages path, to refill
pools transparently from any freeing (not only the freeing of your
subsystem) but such an hook is acceptable. You may need to set
priorities in the criticalpool.c api as well to choose which pool to
refill first, or if to refill them in round robin when they've the same
priority.

I would touch page_alloc.c only with regard of the prioritized pool
refilling with a registration hook and I would definitely not use a
global pool and I wouldn't use __GFP_ bitflag for it.

Then each slab will be allowed to have its criticalpool too, then, not
a global one. A global one driven by the __GFP_CRITICAL flag will
quickly become useless as soon as you've more than one subsystem using
it, plus it unnecessairly mess with page_alloc.c APIs where the only
thing you care about is to catch the freeing operation with a hook.

  reply	other threads:[~2005-12-14 10:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-14  7:50 [RFC][PATCH 0/6] Critical Page Pool Matthew Dobson
2005-12-14  7:52 ` [RFC][PATCH 1/6] Create " Matthew Dobson
2005-12-14 10:48   ` Andrea Arcangeli [this message]
2005-12-14 13:30   ` Rik van Riel
2005-12-14 16:26     ` Matthew Dobson
2005-12-15  3:29       ` Matt Mackall
2005-12-14  7:54 ` [RFC][PATCH 2/6] in_emergency Trigger Matthew Dobson
2005-12-14  7:56 ` [RFC][PATCH 3/6] Slab Prep: get/return_object Matthew Dobson
2005-12-14  8:19   ` Pekka Enberg
2005-12-14 16:26     ` Matthew Dobson
2005-12-14  7:58 ` [RFC][PATCH 4/6] Slab Prep: slab_destruct() Matthew Dobson
2005-12-14  8:37   ` Pekka Enberg
2005-12-14 16:30     ` Matthew Dobson
2005-12-14  7:59 ` [RFC][PATCH 5/6] Slab Prep: Move cache_grow() Matthew Dobson
2005-12-14  8:02 ` [RFC][PATCH 6/6] Critical Page Pool: Slab Support Matthew Dobson
2005-12-14 10:08 ` [RFC][PATCH 0/6] Critical Page Pool Pavel Machek
2005-12-14 12:01   ` Andrea Arcangeli
2005-12-14 13:03     ` Alan Cox
2005-12-14 16:37       ` Matthew Dobson
2005-12-14 19:17         ` Alan Cox
2005-12-15 16:27         ` Pavel Machek
2005-12-14 16:03     ` Matthew Dobson
2005-12-14 15:55   ` Matthew Dobson
2005-12-15 16:26     ` Pavel Machek
2005-12-15 21:51       ` Matthew Dobson
2005-12-16  5:02         ` Sridhar Samudrala

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=20051214104839.GJ23878@opteron.random \
    --to=andrea@suse.de \
    --cc=akpm@osdl.org \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pavel@suse.cz \
    --cc=sri@us.ibm.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;
as well as URLs for NNTP newsgroup(s).