From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 21:06:22 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAABE16A41F for ; Tue, 1 Nov 2005 21:06:22 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711EF43D49 for ; Tue, 1 Nov 2005 21:06:22 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 01 Nov 2005 16:22:36 -0500 From: John Baldwin To: Nate Lawson Date: Tue, 1 Nov 2005 16:05:33 -0500 User-Agent: KMail/1.8.2 References: <4366999B.4070005@root.org> <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> <4367CF1E.2020809@root.org> In-Reply-To: <4367CF1E.2020809@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511011605.34317.jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 21:06:23 -0000 On Tuesday 01 November 2005 03:25 pm, Nate Lawson wrote: > John Baldwin wrote: > > On Oct 31, 2005, at 5:24 PM, Nate Lawson wrote: > >> KTR_WITNESS 10 > > > > This is isolated to one file and should probably be aliased > > to some other bit kind of like how I made KTR_TULIP map to > > KTR_DEV when it was enabled and 0 otherwise based on #ifdef's > > in if_de.c. We might should have one generic bit for > > subsystems to use similar to how device drivers can use > > KTR_DEV. > > Sounds good. KTR_KERN? Maybe KTR_SUBSYS or something. It's all in the kernel. :) If we go with the non-bitmask route this doesn't matter though. > > Another option is to dispense with the whole bitmask idea altogether > > and give each compiled in KTR class its own boolean char with an > > associoted sysctl and loader tunable. You could then allow users to > > specify each class they want to compile in via a separate kernel option > > (KTR_CLASS_FOO) with a special case that KTR_CLASS_ALL would #define > > all of the classes in sys/ktr.h. > > I think that would increase the overhead in checking each boolean in a > loop vs. just a bitmask &, right? Huh? Each check does a bitmask and taht wouldn't change, you'd just be checking the boolean instead. Actually, we do two checks, one is a compile time check, and the other is a runtime check. Here's the CTR() macro: #define CTR6(m, format, p1, p2, p3, p4, p5, p6) do { \ if (KTR_COMPILE & (m)) \ ktr_tracepoint((m), __FILE__, __LINE__, format, \ (u_long)(p1), (u_long)(p2), (u_long)(p3), \ (u_long)(p4), (u_long)(p5), (u_long)(p6)); \ } while(0) So you have one & test there and basically the same thing in the function against the run-time mask. What I'm suggesting would be something like this: #define CTR6(m, format, p1, p2, p3, p4, p5, p6) do { \ if (KTR_COMPILED(m)) \ ktr_tracepoint(KTR_RUNTIME(m), __FILE__, __LINE__, format, \ (u_long)(p1), (u_long)(p2), (u_long)(p3), \ (u_long)(p4), (u_long)(p5), (u_long)(p6)); \ } while(0) Where KTR_COMPILED is a macro that works something like this: #ifdef KTR_ALL #define KTR_COMPILED(x) 1 #else #define KTR_COMPILED(m) m #endif Then for each KTR class, we'd have to have something in sys/ktr.h that did: #ifdef KTR_CLASS_FOO #define KTR_FOO 1 #else #define KTR_FOO 0 #endif (It would be nice if we could hide that in a macro, but I'm not sure cpp will let us do something like: #define KTR_CLASS(m) \ #ifdef KTR_CLASS_##m \ #define KTR_##m 1 \ extern int ktr_class_##m; \ #else \ #define KTR_##m 0 \ #endif ) For the runtime check, you would have: #define KTR_RUNTIME(m) ktr_class_##m // m has to be FOO though, not KTR_FOO You can have some more helper macros ala MALLOC_DEFINE() and MALLOC_DECLARE() for setting up KTR classes to hide as much of this as possible. This should give you the general idea though of what could be done. KTR_DEFINE() would setup the loader tunable and sysctl if the class was enabled, etc. This would get us away from the 32-bit limit with the caveat that you can no longer have a trace be used for multiple classes. That is, you can't do: CTR6(KTR_INTR | KTR_PROC, "blah blah"); If you wanted to do that (I'm not sure we do that every often anyway) you'd now have to have two different trace events for the different classes. We might even be able to store the names of the ktr type in KTR_DEFINE() and make it available in 'show ktr' in ddb as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org