Date: Sun, 30 Jun 2002 23:40:58 -0700 From: Luigi Rizzo <luigi@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> 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: <20020630234058.A90041@iguana.icir.org> In-Reply-To: <20020701160159.C6692-100000@gamplex.bde.org>; from bde@zeta.org.au on Mon, Jul 01, 2002 at 04:13:58PM %2B1000 References: <20020630154951.A20313@grasshopper.cs.duke.edu> <20020701160159.C6692-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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.). As for "generic", it can be easily implemented on the Alpha (maybe on other modern CPUs as well) and it is trivial and correct on uniprocessors, which accounts probably for over 90% of the installed base of FreeBSD machines. It is true that we need to do performance analysis on SMP, but that does not mean that we have to give up a chance of doing that on non-SMP just because the tools we would use do not work on SMP. If I am hungry and have no caviar, I'd rather eat bread than nothing. cheers luigi 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?20020630234058.A90041>