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) Message-ID: <Pine.SV4.3.95.970128101500.4318B-100000@parkplace.cet.co.jp> In-Reply-To: <199701271008.KAA26279@snowcrash.cymru.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970128101500.4318B-100000>