From owner-freebsd-alpha Wed May 30 17:37:47 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id E789037B422 for ; Wed, 30 May 2001 17:37:43 -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 UAA19280; Wed, 30 May 2001 20:37:43 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f4V0bDX54014; Wed, 30 May 2001 20:37:13 -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: <15125.37433.101479.231284@grasshopper.cs.duke.edu> Date: Wed, 30 May 2001 20:37:13 -0400 (EDT) To: Peter Jeremy Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Abyssmal interrupt latency with -current In-Reply-To: <20010531093454.X89950@gsmx07.alcatel.com.au> References: <20010531093454.X89950@gsmx07.alcatel.com.au> 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 Peter Jeremy writes: > > Once control actually gets to siointr, grabbing the sio mutex takes > another 2.7usec (median) - again quite high. Perhaps this is so abysmally slow due to critical_enter/exit. They manipulate the IPL and each make a call into palcode, so they are _very_ expensive. You should time just those functions and see. In fact, you really should un-inline them and give iprobe a try... <...> > Does anyone have any ideas what could be leading to such ludicrous > interrupt latencies? Pal + SMPng + painfully slow hardware == ludicrous interrupt latencies. To be fair, its not all SMPng's fault. Alpha interrupt latencies have always left quite a bit to be desired. Pal adds an extra layer of abstraction and slowness between the actual hardware and the OS. There's no way an alpha can be as tight as a platform where the OS has access to the actual hardware. I suspect the multia's osf/1 palcode may be considerably worse than the palcode on most platforms. Consider that the Multia was never designed to run OSF/1; it was supposed to be a glorified Xterm running alpha NT. I seriously doubt that DEC spent much time optimizing the palcode on a low-margin, loss-leading piece of junk that was dog-slow and essentially obsolete the day it was introduced. I should really resurrect my Pamette and actually compare device interrupt latencies for Tru64, -stable and -current on one of our miatas before they get recycled to other departments. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message