Date: Mon, 1 Jul 2002 18:34:08 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Luigi Rizzo <luigi@FreeBSD.ORG> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, <cvs-committers@FreeBSD.ORG>, <cvs-all@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/i386/isa clock.c src/sys/i386/include param.h src/sys/conf options.i386 Message-ID: <20020701175713.H7244-100000@gamplex.bde.org> In-Reply-To: <20020630234058.A90041@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Jun 2002, Luigi Rizzo wrote: > On Mon, Jul 01, 2002 at 04:13:58PM +1000, Bruce Evans wrote: > ... > > Before adding it anywhere, please implement in a correct place. It > > has no parameters in it; param.h is just being used because pollution > > in it is visible everywhere. > > exactly... but i agree that there might be different places, > e.g. KASSERT is defined in sys/sys/systm.h, would that be a > better place ? I think it should have its own header like ktr, or if it is very small and very machine-dependent then it belongs in <machine/cpu.h>. > > I previously objected to this idea (of a generic lightweight trace > > facility) for similar reasons to phk -- it's very hard to make it > > even two of generic, lightweight and useful. > > This one is certainly lightweight. A lot more than KTR. > > I (biased perspective of course) have found it terribly useful, it > helped me to identify countless performance issues in the network > stack and device drivers, as well as to disprove some misassumptions > that I (and others) made in writing code. Intuition does not always > help, sometimes you need objective numbers to prove what you are > doing, and this is all what this stuff is supposed to do, help you > instrument your code leaving all the expensive processing to userland > (e.g. i use awk scripts to filter and match entries in the event > log and compute times etc.). I find it more convenient to put some simple processing (e.g., filtering and sysctl output formatting) in the kernel. Filtering may stop trace buffers from overflowing very fast, and the output formatting overhead doesn't usually matter since you rarely actually use the sysctl. Both of these require understanding the data. Filtering can be done in a subroutine, but once you have that you can easily add a few lines to it to make it store in a non-generic buffer. I guess the main thing that I object to is using an i386-specific counter. Only very time-critical code can't use nanotime(). nanotime() is more than good enough for disk drivers and serial drivers. It is adequate for mutex profiling modulo some locking problems, so it should be adequate for network drivers. KTR uses get_cyclecount() due to the locking problems, but this doesn't always help since get_cyclecount() is essentially nanotime() on some machines. Kernel profiling on i386's uses cputime(). cputime() has much the same locking problems as KTR. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020701175713.H7244-100000>