From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 24 May 2007 06:39:28 +0200 From: Nick Piggin Subject: Re: [patch 1/3] slob: rework freelist handling Message-ID: <20070524043928.GC12121@wotan.suse.de> References: <20070523074636.GA10070@wotan.suse.de> <20070523193547.GE11115@waste.org> <20070524033925.GD14349@wotan.suse.de> <20070524041339.GC20252@wotan.suse.de> <20070524043144.GB12121@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Matt Mackall , Andrew Morton , Linux Memory Management List List-ID: On Wed, May 23, 2007 at 09:35:52PM -0700, Christoph Lameter wrote: > On Thu, 24 May 2007, Nick Piggin wrote: > > > I'll take an educated guess and say that SLUB would have more external > > fragmentation which would be especially pronounced in small memory > > setups. Also, that SLUB's kmalloc slabs would suffer from a lot more > > internal fragmentation too, which could be equally significant if not > > more (I think this would become relatively more significant than external > > fregmentation as you increased memory size). > > Hmmmm... Could be. The kmalloc array is potentially wasting a lot of > memory. I added more smaller kmalloc array elements to SLUB to avoid that > but maybe that is not enough. Don't forget that on small memory systems, this could actually be _worse_ because you might be increasing external fragmentation (ie. if there are only few kmallocs in each slab). So it might also be an idea to try reducing them as well. > > If you don't think the test is very interesting, I could try any other > > sort of test and with i386 or x86-64 if you like. > > Let me try some tests on my own first. Just ran a SLOB baseline, should > have some numbers soon. Sure. -- 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