Date: Tue, 16 Oct 2001 15:58:32 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Luigi Rizzo <rizzo@aciri.org> Cc: arch@FreeBSD.org Subject: Re: where to put support for timestamping kernel events ? Message-ID: <XFMail.011016155832.jhb@FreeBSD.org> In-Reply-To: <20011016104601.F63982@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-Oct-01 Luigi Rizzo wrote: > On Tue, Oct 16, 2001 at 10:34:18AM -0700, John Baldwin wrote: >> > >> > what is KTR ? any pointers ? (sorry but i am not familiar >> > with -current, where this seems to be...) >> >> KTR is an kernel event trace mechanism. current includes both ktr(4) and >> ktr(9) manpages. It basically allows you to log events in a printf-style >> fashion in the kernel including a timestamp among other things. > > i see. The thing i was suggesting is much more lightweight (and > faster i presume). Yes, it might very well be. Esp. more so than the KTR_EXTEND version. The !KTR_EXTEND case needs a hacked up printf(), however, that accepts it's arguments as longs and only uses the types in the format string for casting and rendering purposes. >> >> Unfortunately, the KTR buffr isn't exported via sysctl(8) at the moment. >> > >> > well, the sysctl export is really trivial to do. >> >> Except on an SMP system when aother CPU may be sticking items in the buffer >> while you are exporting it. > > isn't that true for all sysctl-exported items ? > > Actually, the problem i see for exporting the buffer is that in > one of the modes (!KTR_EXTEND) it stores references to kernel > addresses into the buffer, so you need a bit of in-kernel processing > to make this info useful for userland (presumably using a SYSCTL_PROC > thing to do this processing and return some significant info). > > Anyways -- it looks like the timestamping i was suggesting can > be incorporated in ktr, and ktr-like things can be then MFC-ed > to stable. Any objections to this ? KTR already has the timestamping, so it is probably fine. One problem is that the current timestamping is done solely with the timecounter code, not using the cyclecounts. It might be feasible to change it to use a cycle count that use the get_cyclecount() function in machine/cpu.h. However, that is subject to the recursion on the clock lock problem for the KTR_LOCK case in nanotime() if the TSC isn't present. The KTR code on 4.x probably won't need the atomic_cmpset() or the critical seciton stuff (just use splhigh() instead) so long as it is always used under the Giant lock. > cheers > luigi -- 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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011016155832.jhb>