linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Dobson <colpatch@us.ibm.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: linux-kernel@vger.kernel.org, sri@us.ibm.com, andrea@suse.de,
	pavel@suse.cz, linux-mm@kvack.org
Subject: Re: [patch 0/9] Critical Mempools
Date: Thu, 26 Jan 2006 15:32:14 -0800	[thread overview]
Message-ID: <43D95BFE.4010705@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0601261516160.18716@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> On Thu, 26 Jan 2006, Matthew Dobson wrote:
> 
> 
>>>All subsystems will now get more complicated by having to add this 
>>>emergency functionality?
>>
>>Certainly not.  Only subsystems that want to use emergency pools will get
>>more complicated.  If you have a suggestion as to how to implement a
>>similar feature that is completely transparent to its users, I would *love*
> 
> 
> I thought the earlier __GFP_CRITICAL was a good idea.

Well, I certainly could have used that feedback a month ago! ;)  The
general response to that patchset was overwhelmingly negative.  Yours is
the first vote in favor of that approach, that I'm aware of.


>>to hear it.  I have tried to keep the changes to implement this
>>functionality to a minimum.  As the patches currently stand, existing slab
>>allocator and mempool users can continue using these subsystems without
>>modification.
> 
> 
> The patches are extensive and the required changes to subsystems in order 
> to use these pools are also extensive.

I can't really argue with your first point, but the changes required to use
the pools should actually be quite small.  Sridhar (cc'd on this thread) is
working on the changes required for the networking subsystem to use these
pools, and it looks like the patches will be no larger than the ones from
the last attempt.


>>>There surely must be a better way than revising all subsystems for 
>>>critical allocations.
>>
>>Again, I could not find any way to implement this functionality without
>>forcing the users of the functionality to make some, albeit very minor,
>>changes.  Specific suggestions are more than welcome! :)
> 
> 
> Gfp flag? Better memory reclaim functionality?

Well, I've got patches that implement the GFP flag approach, but as I
mentioned above, that was poorly received.  Better memory reclaim is a
broad and general approach that I agree is useful, but will not necessarily
solve the same set of problems (though it would likely lessen the severity
somewhat).

-Matt

  reply	other threads:[~2006-01-26 23:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-25 19:39 [patch 0/9] Critical Mempools Matthew Dobson
2006-01-26 17:57 ` Christoph Lameter
2006-01-26 23:01   ` Matthew Dobson
2006-01-26 23:18     ` Christoph Lameter
2006-01-26 23:32       ` Matthew Dobson [this message]
2006-01-27  0:03         ` Benjamin LaHaise
2006-01-27  0:27           ` Matthew Dobson
2006-01-27  7:35             ` Pekka Enberg
2006-01-27 10:10               ` Paul Jackson
2006-01-27 11:07                 ` Pekka Enberg
2006-01-28  0:41                   ` Matthew Dobson
2006-01-28 10:21                     ` Pekka Enberg
2006-01-30 22:38                       ` Matthew Dobson
2006-01-27 15:36             ` Jan Kiszka
2006-01-27  8:34           ` Sridhar Samudrala
2006-01-27  8:29         ` 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=43D95BFE.4010705@us.ibm.com \
    --to=colpatch@us.ibm.com \
    --cc=andrea@suse.de \
    --cc=clameter@engr.sgi.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).