From owner-freebsd-alpha Fri Mar 30 6:48:11 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 9451237B726 for ; Fri, 30 Mar 2001 06:48:01 -0800 (PST) (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 JAA22723; Fri, 30 Mar 2001 09:48:00 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f2UElUS83683; Fri, 30 Mar 2001 09:47:30 -0500 (EST) (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: <15044.40066.746054.729549@grasshopper.cs.duke.edu> Date: Fri, 30 Mar 2001 09:47:30 -0500 (EST) To: mjacob@feral.com Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: do we care about performance yet? In-Reply-To: References: <15044.1867.943183.224703@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > > Isn't this just basically saying you're i/o bound? Sorta. And user-space CPU bound as well. The lockmgr was a somewhat surprising standout (1.5% of the time doing a buildworld is spent in lockmgr). I'm thinking it would be interesting for people to occasionally profile the kernel after major infastructure changes & want to showcase what Iprobe can do (at less than 5% overhead, probably more like 1%). I profiled a buildworld because that's the "benchmark" people seem to care about. The netperf TCP streams are much more interesting. In the non witness case (http://www.cs.duke.edu/~gallatin/iprobe_current/netperf.120sec), ithread_loop() is at nearly 7% for a 100Mb TCP stream. Nearly all of that is assigned to the mtx_unlock_spin(&sched_lock) line at the bottom of the code. I haven't disassembled it, but I suspect that its just an effect of cache misses as we reschedule into the ithread loop. In the witness case, (http://www.cs.duke.edu/~gallatin/iprobe_current/netperf.witness.120sec) we see how expensive the witness functionality really is... Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message