From owner-freebsd-hackers  Mon Jan 27 17:32:22 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA05436
          for hackers-outgoing; Mon, 27 Jan 1997 17:32:22 -0800 (PST)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05425
          for <hackers@freebsd.org>; Mon, 27 Jan 1997 17:32:20 -0800 (PST)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id BAA04689; Tue, 28 Jan 1997 01:30:46 GMT
Date: Tue, 28 Jan 1997 10:30:46 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: Alan Cox <alan@cymru.net>
cc: Julian Elischer <julian@whistle.com>, proff@suburbia.net, dg@root.com,
        hackers@freebsd.org, alan.cox@linux.org
Subject: Re: SLAB stuff, and applications to current net code (fwd)
In-Reply-To: <199701271008.KAA26279@snowcrash.cymru.net>
Message-ID: <Pine.SV4.3.95.970128101500.4318B-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Mon, 27 Jan 1997, Alan Cox wrote:

> Its pretty trivial to inspect the Linux and BSD code to see that almost all
> objects are of the form
> 
> 
> 	struct
> 	{
> 		most used field
> 		regularly used field
> 		buf[blah]; /* rarely accessed */
> 	}
> 	[memory allocator slop - never used]
> 
> In the end I pulled some messy tricks in Linux 2.0 to keep the cache a bit
> saner by building sk_buff's (mbufs to the BSD world) with the buffer
> structure at the tail of the object .. ie
> 
> 
> 	ptr=malloc(size+struct+15)
> 	struct=ptr-sizeof(struct)
> 	round_down(ptr,16);
> 	struct->data=ptr
> 
> That combined with the fact most linux sk_buff's have the major headers on
> the 2nd and 3rd cache line into the buffer gave me a performance improvement
> I could benchmark.
> 
> The right answer in current literature is undoubtedly a SLAB allocator and
> that is where we are going at the moment.

I wonder what would actually perform better in practice, struct member
order hackery or a SLAB allocator with its processor cache coloring along
with all it's overhead in maintaining a linked list of memory slabs with
embedded object arrays and "in-band"  free object lists. 

On the call side the abstraction sure is pretty with it's object
constructor and destructor args.

It seems that there are things to be gained and things that will be lost.
This will be an interesting development to follow.

Regards,


Mike Hancock