Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs

From: Attilio Rao <attilio_at_freebsd.org>
Date: Tue, 16 Jan 2007 21:36:16 +0100
2007/1/16, John Baldwin <jhb_at_freebsd.org>:
> On Tuesday 16 January 2007 11:51, Attilio Rao wrote:
> > 2006/7/28, Attilio Rao <attilio_at_freebsd.org>:
> > >
> > > After some thinking, I think it's better using init/fini methods
> > > (since they hide the sizeof(struct turnstile) with size parameter).
> > >
> > > Feedbacks and comments are welcome:
> > > http://users.gufi.org/~rookie/works/patches/uma_sync_init.diff
> >
> > [CC'ed all the interested people]
> >
> > Even if a long time is passed I did some benchmarks based on ebizzy tool.
> > This program claims to reproduce a real httpd server behaviour and is
> > used into the Linux world for benchmarks, AFAIK.
> > I think that results of the comparison on this patch is very
> > interesting, and I think it worths a commit :)
> > I think that results can be even better on a Xeon machine (I had no
> > chance to reproduce this on some of these).
> > (Results taken in consideration have been measured after some starts,
> > in order to minimize caching differences).
> >
> > The patch:
> > http://users.gufi.org/~rookie/works/patches/ts-sq/ts-sq.diff
>
> Looks good.  Some minor nits are that in subr_turnstile.c in the comment I
> would say "a turnstile is allocated" rather than "a turnstile is got from a
> specific UMA zone" as it reads a little bit clearer.  Also, I would
> say "Allocate a" rather than "Get a" for the two _alloc() functions.  Also,
> why not just use UMA_ALIGN_CACHE and make UMA_ALIGN_CACHE (128 - 1) on i386
> and amd64 rather than adding a new UMA_ALIGN_SYNC?

I was thinking that in this way anyone who wants to replace the
syncronizing primitive boundary to an appropriate value can do it.
I just used UMA_ALIGN_CACHE as default value beacause I don't know the
better boundary (for syncronizing primitives) for other arches.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Tue Jan 16 2007 - 19:36:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC