Date: Thu, 5 Sep 2002 10:48:25 +0200 From: Bernd Walter <ticso@cicely5.cicely.de> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: ticso@cicely.de, John Baldwin <jhb@FreeBSD.ORG>, freebsd-alpha@FreeBSD.ORG Subject: Re: alpha performance on -current Message-ID: <20020905084824.GJ87724@cicely5.cicely.de> In-Reply-To: <15734.39976.326598.176742@grasshopper.cs.duke.edu> References: <XFMail.20020904090455.jhb@FreeBSD.org> <15734.29725.515274.183629@grasshopper.cs.duke.edu> <20020904223255.GI87724@cicely5.cicely.de> <15734.39976.326598.176742@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 04, 2002 at 07:50:00PM -0400, Andrew Gallatin wrote: > > 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. The one in atomic_cmpset_64 is obsolete. atomic_cmpset_acq_64 is correct. The problem I have with removing the barrier in atomic_cmpset_64 and the like is that it makes an additional difference to i386 and I think we already have enough alpha only bugs to build a new set just for a bit performance. > 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? Sounds logical. But if you want to implement specialized tuning in regards of CPU and UP, then there is much more that can be done. Terry has brought up many interessting ideas of what can be done if you know your machine. > > 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. What I wrote was only the short story for the intended use of the atomic functions. Memory barries still have their normal semantics in respect to other memory regions so if you write data into memory, do a barrier and tell the device to dma it, then the barrier still works because the device register is marked uncacheable. But barriers shouldn't be very expensive, what makes them expensive is the required combination with locked instuctions. > FWIW, my machine survived the buildworld. The removal of the memory > barriers chopped nearly 7 minutes off the time: There is not a big chance to loose the insturction ordering race I guess. > with MB: > 8699.25 real 6985.64 user 1379.72 sys > > without MB: > 8298.44 real 7010.03 user 969.02 sys Would be insteresting what happens if you remove only the obsolete barriers. What is required is the following: ... /* acq */ atomic (locked) memory access mb ... /* rel */ mb atomic (locked) memory access ... But what we currently have is ... /* acq */ atomic (locked) memory access mb mb ... /* rel */ mb atomic (locked) memory access mb ... -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de 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?20020905084824.GJ87724>