All of lore.kernel.org
 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:01:44 -0800	[thread overview]
Message-ID: <43D954D8.2050305@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0601260954540.15128@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> On Wed, 25 Jan 2006, Matthew Dobson wrote:
> 
> 
>>Using this new approach, a subsystem can create a mempool and then pass a
>>pointer to this mempool on to all its slab allocations.  Anytime one of its
>>slab allocations needs to allocate memory that memory will be allocated
>>through the specified mempool, rather than through alloc_pages_node() directly.
> 
> 
> 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*
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.


>>Feedback on these patches (against 2.6.16-rc1) would be greatly appreciated.
> 
> 
> 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! :)

Thanks!

-Matt

WARNING: multiple messages have this Message-ID (diff)
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:01:44 -0800	[thread overview]
Message-ID: <43D954D8.2050305@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0601260954540.15128@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> On Wed, 25 Jan 2006, Matthew Dobson wrote:
> 
> 
>>Using this new approach, a subsystem can create a mempool and then pass a
>>pointer to this mempool on to all its slab allocations.  Anytime one of its
>>slab allocations needs to allocate memory that memory will be allocated
>>through the specified mempool, rather than through alloc_pages_node() directly.
> 
> 
> 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*
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.


>>Feedback on these patches (against 2.6.16-rc1) would be greatly appreciated.
> 
> 
> 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! :)

Thanks!

-Matt

--
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:[~2006-01-26 23:01 UTC|newest]

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