All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sridhar Samudrala <sri@us.ibm.com>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Matthew Dobson <colpatch@us.ibm.com>,
	Christoph Lameter <clameter@engr.sgi.com>,
	linux-kernel@vger.kernel.org, andrea@suse.de, pavel@suse.cz,
	linux-mm@kvack.org
Subject: Re: [patch 0/9] Critical Mempools
Date: Fri, 27 Jan 2006 00:34:26 -0800	[thread overview]
Message-ID: <43D9DB12.20706@us.ibm.com> (raw)
In-Reply-To: <20060127000304.GG10409@kvack.org>

Benjamin LaHaise wrote:
> On Thu, Jan 26, 2006 at 03:32:14PM -0800, Matthew Dobson wrote:
>   
>>> 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.
>>     
>
> Personally, I'm more in favour of a proper reservation system.  mempools 
> are pretty inefficient.  Reservations have useful properties, too -- one 
> could reserve memory for a critical process to use, but allow the system 
> to use that memory for easy to reclaim caches or to help with memory 
> defragmentation (more free pages really helps the buddy allocator).
>
>   
>>> 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).
>>     
>
> Which areas are the priorities for getting this functionality into?  
> Networking over particular sockets?  A GFP_ flag would plug into the current 
> network stack trivially, as sockets already have a field to store the memory 
> allocation flags.
>   
Yes, i have posted patches that use this exact approach last month that 
use a critical page pool with
GFP_CRITICAL flag.
      http://lkml.org/lkml/2005/12/14/65
      http://lkml.org/lkml/2005/12/14/66

Thanks
Sridhar


WARNING: multiple messages have this Message-ID (diff)
From: Sridhar Samudrala <sri@us.ibm.com>
To: Benjamin LaHaise <bcrl@kvack.org>
Cc: Matthew Dobson <colpatch@us.ibm.com>,
	Christoph Lameter <clameter@engr.sgi.com>,
	linux-kernel@vger.kernel.org, andrea@suse.de, pavel@suse.cz,
	linux-mm@kvack.org
Subject: Re: [patch 0/9] Critical Mempools
Date: Fri, 27 Jan 2006 00:34:26 -0800	[thread overview]
Message-ID: <43D9DB12.20706@us.ibm.com> (raw)
In-Reply-To: <20060127000304.GG10409@kvack.org>

Benjamin LaHaise wrote:
> On Thu, Jan 26, 2006 at 03:32:14PM -0800, Matthew Dobson wrote:
>   
>>> 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.
>>     
>
> Personally, I'm more in favour of a proper reservation system.  mempools 
> are pretty inefficient.  Reservations have useful properties, too -- one 
> could reserve memory for a critical process to use, but allow the system 
> to use that memory for easy to reclaim caches or to help with memory 
> defragmentation (more free pages really helps the buddy allocator).
>
>   
>>> 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).
>>     
>
> Which areas are the priorities for getting this functionality into?  
> Networking over particular sockets?  A GFP_ flag would plug into the current 
> network stack trivially, as sockets already have a field to store the memory 
> allocation flags.
>   
Yes, i have posted patches that use this exact approach last month that 
use a critical page pool with
GFP_CRITICAL flag.
      http://lkml.org/lkml/2005/12/14/65
      http://lkml.org/lkml/2005/12/14/66

Thanks
Sridhar

--
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>

  parent reply	other threads:[~2006-01-27  8:34 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
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 [this message]
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=43D9DB12.20706@us.ibm.com \
    --to=sri@us.ibm.com \
    --cc=andrea@suse.de \
    --cc=bcrl@kvack.org \
    --cc=clameter@engr.sgi.com \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pavel@suse.cz \
    /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.