From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <429E483D.8010106@yahoo.com.au> Date: Thu, 02 Jun 2005 09:43:57 +1000 From: Nick Piggin MIME-Version: 1.0 Subject: Re: Avoiding external fragmentation with a placement policy Version 12 References: <20050531112048.D2511E57A@skynet.csn.ul.ie> <429E20B6.2000907@austin.ibm.com> <429E4023.2010308@yahoo.com.au> <423970000.1117668514@flay> In-Reply-To: <423970000.1117668514@flay> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: "Martin J. Bligh" Cc: jschopp@austin.ibm.com, Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@osdl.org List-ID: Martin J. Bligh wrote: > --On Thursday, June 02, 2005 09:09:23 +1000 Nick Piggin wrote: > > >>It adds a lot of complexity to the page allocator and while >>it might be very good, the only improvement we've been shown >>yet is allocating lots of MAX_ORDER allocations I think? (ie. >>not very useful) > > > I agree that MAX_ORDER allocs aren't interesting, but we can hit > frag problems easily at way less than max order. CIFS does it, NFS > does it, jumbo frame gigabit ethernet does it, to name a few. The > most common failure I see is order 3. > Still? We had a lot of problems with kswapd not doing its job properly, and min_free_kbytes reserve was buggy... But if you still trigger it, I would be interested to see traces. I don't frequently test things like XFS, or heavy gige+jumbo loads. > Keep a machine up for a while, get it thoroughly fragmented, then > push it reasonably hard constant pressure, and try allocating anything > large. > > Seems to me we're basically pointing a blunderbuss at memory, and > blowing away large portions, and *hoping* something falls out the > bottom that's a big enough chunk? > Yeah more or less. But with the fragmentation patch, it by no means becomes an exact science ;) I wouldn't have thought it would make it hugely easier to free an order 2 or 3 area memory block on a loaded machine. It does make MAX_ORDER allocations _possible_ when previously they wouldn't have been, simply by virtue of trying to put all memory that it knows is reclaimable in a MAX_ORDER area. When memory fills up and you need an order 3 allocation, you're more or less in the same boat AFAIKS. Why not just have kernel allocations going from the bottom up, and user allocations going from the top down. That would get you most of the way there, wouldn't it? (disclaimer: I could well be talking shit here). -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -- 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: aart@kvack.org