From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 26 Jan 2006 15:18:18 -0800 (PST) From: Christoph Lameter Subject: Re: [patch 0/9] Critical Mempools In-Reply-To: <43D954D8.2050305@us.ibm.com> Message-ID: References: <1138217992.2092.0.camel@localhost.localdomain> <43D954D8.2050305@us.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Matthew Dobson Cc: linux-kernel@vger.kernel.org, sri@us.ibm.com, andrea@suse.de, pavel@suse.cz, linux-mm@kvack.org List-ID: 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. > 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. > > 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? -- 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: email@kvack.org