From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Jan 2006 02:51:26 -0800 From: Paul Jackson Subject: Re: [patch 3/9] mempool - Make mempools NUMA aware Message-Id: <20060127025126.c95f8002.pj@sgi.com> In-Reply-To: <43D96A93.9000600@us.ibm.com> References: <20060125161321.647368000@localhost.localdomain> <1138233093.27293.1.camel@localhost.localdomain> <43D953C4.5020205@us.ibm.com> <43D95A2E.4020002@us.ibm.com> <43D96633.4080900@us.ibm.com> <43D96A93.9000600@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Matthew Dobson Cc: clameter@engr.sgi.com, linux-kernel@vger.kernel.org, sri@us.ibm.com, andrea@suse.de, pavel@suse.cz, linux-mm@kvack.org List-ID: Matthew wrote: > I'm glad we're on the same page now. :) And yes, adding four "duplicate" > *_mempool allocators was not my first choice, but I couldn't easily see a > better way. I hope the following comments aren't too far off target. I too am inclined to prefer the __GFP_CRITICAL approach over this. That or Andrea's suggestion, which except for a free hook, was entirely outside of the page_alloc.c code paths. Or Alan's suggested revival of the old code to drop non-critical network patches in duress. I am tempted to think you've taken an approach that raised some substantial looking issues: * how to tell the system when to use the emergency pool * this doesn't really solve the problem (network can still starve) * it wastes memory most of the time * it doesn't really improve on GFP_ATOMIC and just added another substantial looking issue: * it entwines another thread of complexity and performance costs into the important memory allocation code path. Progress in the wrong direction ;). > With large machines, especially as > those large machines' workloads are more and more likely to be partitioned > with something like cpusets, you want to be able to specify where you want > your reserve pool to come from. Cpusets is about performance, not correctness. Anytime I get cornered in the cpuset code, I prefer violating the cpuset containment, over serious system failure. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.925.600.0401 -- 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