From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 03 Jun 2005 07:00:59 -0700 From: "Martin J. Bligh" Reply-To: "Martin J. Bligh" Subject: Re: Avoiding external fragmentation with a placement policy Version 12 Message-ID: <370550000.1117807258@[10.10.2.4]> In-Reply-To: References: <20050531112048.D2511E57A@skynet.csn.ul.ie> <429E20B6.2000907@austin.ibm.com><429E4023.2010308@yahoo.com.au> <423970000.1117668514@flay><429E483D.8010106@yahoo.com.au> <434510000.1117670555@flay><429E50B8.1060405@yahoo.com.au> <429F2B26.9070509@austin.ibm.com><1117770488.5084.25.camel@npiggin-nld.site> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mm@kvack.org Return-Path: To: Mel Gorman , Nick Piggin Cc: jschopp@austin.ibm.com, linux-mm@kvack.org, lkml , Andrew Morton List-ID: > Does it need more documentation? If so, I'll write up a detailed blurb on > how it works and drop it into Documentation/ > >> Although I can't argue that a buddy allocator is no good without >> being able to satisfy higher order allocations. > > Unfortunately, it is a fundemental flaw of the buddy allocator that it > fragments badly. The thing is, other allocators that do not fragment are > also slower. Do we care? 99.9% of allocations are fronted by the hot/cold page cache now anyway ... and yes, I realise that things popping in/out of that obviously aren't going into the "defrag" pool, but still, it should help. I suppose all we're slowing down is higher order allocs anyway, which is the uncommon case, but ... worth thinking about. M. -- 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