From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 24 May 2007 06:01:49 +0200 From: Nick Piggin Subject: Re: [patch 1/3] slob: rework freelist handling Message-ID: <20070524040149.GB20252@wotan.suse.de> References: <20070523051152.GC29045@wotan.suse.de> <20070523052206.GD29045@wotan.suse.de> <20070523061702.GA9449@wotan.suse.de> <20070523074636.GA10070@wotan.suse.de> <20070524032417.GC14349@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 08:49:30PM -0700, Christoph Lameter wrote: > On Thu, 24 May 2007, Nick Piggin wrote: > > > The reason SLOB is so space efficient really comes from Matt's no > > compromises design. The thrust of my patches were after seeing how slow > > it was on my 4GB system while testing the RCU implementation. They > > were primarily intended to speed up the thing, but retain all the same > > basic allocation algorithms -- a quirk of my implementation allowed > > smaller freelist indexes which was a bonus, but as Matt said, slob was > > still more efficient before the change. > > Well as far as I understand Matt it seems that you still need 2 bytes per > alloc. That is still more than 0 that SLUB needs. That's true, but I think the more relevant number is that SLUB needs 400K more memory to boot into /bin/bash. > > What SLUB idea did you think I copied anyway? > > The use of the page struct. The general use of struct page to store page metadata other than pagecache? I guess not, because that predates SLUB and even SLAB. You've got a freelist pointer in there, so maybe that's what you mean. I was hoping for something that I actually can "steal" to make SLOB even better ;) -- 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