Date: Wed, 4 Sep 2002 19:50:00 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: ticso@cicely.de Cc: John Baldwin <jhb@FreeBSD.ORG>, freebsd-alpha@FreeBSD.ORG Subject: Re: alpha performance on -current Message-ID: <15734.39976.326598.176742@grasshopper.cs.duke.edu> In-Reply-To: <20020904223255.GI87724@cicely5.cicely.de> References: <XFMail.20020904090455.jhb@FreeBSD.org> <15734.29725.515274.183629@grasshopper.cs.duke.edu> <20020904223255.GI87724@cicely5.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter writes:
> On Wed, Sep 04, 2002 at 04:59:09PM -0400, Andrew Gallatin wrote:
> >
> > # ./lat_syscall null
> > Simple syscall: 2.0178 microseconds
> > # ./lat_syscall null
> > Simple syscall: 2.0333 microseconds
> > # sysctl -w kern.giant.proc=0
> > kern.giant.proc: 1 -> 0
> > # ./lat_syscall null
> > Simple syscall: 1.6360 microseconds
> > # ./lat_syscall null
> > Simple syscall: 1.6333 microseconds
> >
> >
> > Is the locking overhead this bad on x86? It looks downright
> > embarrassing on alpha. Can anything be done about it? Are the
> > memory barriers in atomic_cmpset_acq_* really needed? They have the
> > look of belt & suspenders code..
>
> They are needed in _acq_ and _rel_ because they are used to build
> mutexes.
atomic_cmpset_acq_64 calls atomic_cmpset_64() followed by a memory barrier..
atomic_cmpset_64() ends with a memory barrier. So isn't the
memory barrier in atomic_cmpset_acq_64() extranious? Eg, you have 2
memory barriers back to back.
At any rate, the overhead just plain stinks. At nearly 0.5 us per
mutex, they are just way too expensive.
> You even need them on UP systems to enshure instruction order.
Alphas older than ev6 are in-order processors with regard to
instruction order, so presumably they are not needed on ev56 and older
machines?
> Some barriers can be removed in other atomic functions or replaced
> with write barriers.
> Currently our alpha_wmb() is mappend to mb, which is done because it's
> also done in NetBSD - possibly as a workaround for a unnamed problem.
>
> > FWIW, The appended diff to remove them reducess null system call
> > latency to 1.6us with kern.giant.proc=1, and 1.4us with
> > kern.giant.proc=0. I'm about to start a buildworld with it, but I
> > don't have any SMP boxes.
>
> What kind of CPU is in your XP1000?
21264.
> On >= 21164 the CPU can be initialised into UP operation so that mb
> and wmb fall back to just an contraint on instruction order.
> Also locked instructions can be handled inside the CPU in that case.
Please elaborate. How does this work with respect to devices? That
sounds quite scary for the atomic code in general.
FWIW, my machine survived the buildworld. The removal of the memory
barriers chopped nearly 7 minutes off the time:
with MB:
8699.25 real 6985.64 user 1379.72 sys
without MB:
8298.44 real 7010.03 user 969.02 sys
Drew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15734.39976.326598.176742>