From owner-freebsd-arch Tue Oct 16 23: 2: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1FF4B37B407; Tue, 16 Oct 2001 23:02:05 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA02519; Wed, 17 Oct 2001 16:01:55 +1000 Date: Wed, 17 Oct 2001 16:01:05 +1000 (EST) From: Bruce Evans X-X-Sender: To: John Baldwin Cc: Luigi Rizzo , Subject: Re: where to put support for timestamping kernel events ? In-Reply-To: Message-ID: <20011017154118.A14701-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 16 Oct 2001, John Baldwin wrote: > On 16-Oct-01 Luigi Rizzo wrote: > > On Tue, Oct 16, 2001 at 09:27:07AM -0700, John Baldwin wrote: > >> > >> On 15-Oct-01 Luigi Rizzo wrote: > >> > [Apparently this kind of question is better asked on -arch, > >> > so sorry for the repost, here it goes again... and in the meantime > >> > i have had some time to elaborate on names and locations.] In your tree seems to be the best place to put it. I have almost identical code in my tree in the fd driver (fd_event()), and a modified version of it for interrupt threads (it_event()), and somewhat different versions of it in the da driver and the (obsolete) wd driver, all with private buffers (currently mostly hard-coded down to size 1 event since I'm not using them). I feel that generalizing this with lose most of the benefits of it (simple interface, efficiency, and tailoring to the type of events being monitored, including separate buffers). > >> Note that KTR has somewhat similar support for this, though it currently > > > > 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. KTR already loses all the benefits so it doesn't need to be reinvented :-). > >> doesn't use the TSC. It could be changed to use cpu_cyclecount() (which is > >> a > >> MI interface which uses the TSC when it can) perhaps which might help. > >> 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. The TSC and cpu_getcyclecount() don't work right (for this) under SMP either. KTR is correct to not use them. After you wrap get_cyclecount() with the #ifdef and "if ()" mess to make it portable, it would be little faster than nanotime() or timecounter->tc_get_timecounter() (the latter is almost just rdtsc() indirectly through a function call if possible). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message