Date: Fri, 30 Mar 2001 15:01:21 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-alpha@FreeBSD.org, mjacob@feral.com Subject: Re: do we care about performance yet? Message-ID: <XFMail.010330150121.jhb@FreeBSD.org> In-Reply-To: <15044.40066.746054.729549@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30-Mar-01 Andrew Gallatin wrote: > > 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). Remember that VFS uses lockmgr all over the place, as does the buffer cache, so anything I/O bound is going to be using lockmgr() a lot. > 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. That is quite possible, as the mutex exit is the first thing we do after returning from mi_switch, and mi_switch() doesn't do much after returning from cpu_switch(), not to mention that mi_switch() might still be cached by a read-ahead style cache since we were just in it when we switched out. > In the witness case, > (http://www.cs.duke.edu/~gallatin/iprobe_current/netperf.witness.120sec) > we see how expensive the witness functionality really is... Yes, it is not cheap. The recent changes to it also made it more expensive in the spinlock case. The witness_lock_list_{get,free} functions manage the static pool of struct lock_list_entry's that are used to build the per-cpu list of spinlocks and per-process list of sleeplocks, hence they are rather high on the list. > Drew -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010330150121.jhb>