From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Landley Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 Date: Sat, 5 Nov 2005 20:25:47 -0600 References: <20051104201248.GA14201@elte.hu> <200511042343.27832.ak@suse.de> <436D5CCD.3050901@acm.org> In-Reply-To: <436D5CCD.3050901@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511052025.48976.rob@landley.net> Sender: owner-linux-mm@kvack.org Return-Path: To: Zan Lynx Cc: Andi Kleen , Gregory Maxwell , Andy Nelson , mingo@elte.hu, akpm@osdl.org, arjan@infradead.org, arjanv@infradead.org, haveblue@us.ibm.com, kravetz@us.ibm.com, lhms-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mbligh@mbligh.org, mel@csn.ul.ie, nickpiggin@yahoo.com.au, torvalds@osdl.org List-ID: On Saturday 05 November 2005 19:30, Zan Lynx wrote: > > None of this is very attractive. > > You could allow the 'hugetlb zone' to shrink, allowing more kernel > allocations. User pages at the boundary would be moved to make room. Please make that optional if you do. In my potential use case, an OOM kill lets the administrator know they've got things configure wrong so they can can fix it and try again. Containing and viciously reaping things like dentries is the behavior I want out of it. Also, if you do shrink the hugetlb zone it might be possible to opportunistically expand it back to its original size. There's no guarantee that a given kernel allocation will ever go away, but if it _does_ go away then the hugetlb zone should be able to expand to the next blocking allocation or the maximum size, whichever comes first. (Given that my understanding of the layout may not match reality at all; don't ask me how the discontiguous memory stuff would work in here...) Rob -- 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