From owner-freebsd-alpha Wed Sep 4 16:50:36 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CB4E37B400; Wed, 4 Sep 2002 16:50:32 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B77643E6E; Wed, 4 Sep 2002 16:50:31 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id TAA04182; Wed, 4 Sep 2002 19:50:30 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g84No0D57025; Wed, 4 Sep 2002 19:50:00 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15734.39976.326598.176742@grasshopper.cs.duke.edu> Date: Wed, 4 Sep 2002 19:50:00 -0400 (EDT) To: ticso@cicely.de Cc: John Baldwin , freebsd-alpha@FreeBSD.ORG Subject: Re: alpha performance on -current In-Reply-To: <20020904223255.GI87724@cicely5.cicely.de> References: <15734.29725.515274.183629@grasshopper.cs.duke.edu> <20020904223255.GI87724@cicely5.cicely.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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