Date: Thu, 30 Jun 2005 10:42:08 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: ant <andrit@ukr.net> Cc: hackers@freebsd.org Subject: Re: hot path optimizations in uma_zalloc() & uma_zfree() Message-ID: <20050630174208.GL727@funkthat.com> In-Reply-To: <000d01c57cf7$b9b6f9f0$29931bd9@ertpc> References: <000d01c57cf7$b9b6f9f0$29931bd9@ertpc>
next in thread | previous in thread | raw e-mail | index | archive | help
ant wrote this message on Thu, Jun 30, 2005 at 01:08 +0300:
> I just tryed to make buckets management in perCPU cache like in
> Solaris (see paper of Jeff Bonwick - Magazines and Vmem)
> and got perfomance gain around 10% in my test program.
> Then i made another minor code optimization and got another 10%.
> The program just creates and destroys sockets in loop.
>
> I suppose the reason of first gain lies in increasing of cpu cache hits.
> In current fbsd code allocations and freeings deal with
> separate buckets. Buckets are changed when one of them
> became full or empty first. In Solaris this work is pure LIFO:
> i.e. alloc() and free() work with one bucket - the current bucket
> (it is called magazine there), that's why cache hit rate is bigger.
If you do like the paper does, and use the buckets for allocating buckets,
I would recommend you drop the free bucket list from the pool... If
bucket allocations are as cheap as they are suppose to be, there is no
need to keep a local list of empty buckets.. :)
Just following the principal stated in the paper of letting well
optimized parts do their part...
P.S. I have most of a userland implementation of this done. Since someone
else has done kernel, I'll solely target userland for the code now.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050630174208.GL727>