Date: Tue, 1 Nov 2005 16:05:33 -0500 From: John Baldwin <jhb@freebsd.org> To: Nate Lawson <nate@root.org> Cc: arch@freebsd.org Subject: Re: KTR changes Message-ID: <200511011605.34317.jhb@freebsd.org> In-Reply-To: <4367CF1E.2020809@root.org> References: <4366999B.4070005@root.org> <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> <4367CF1E.2020809@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511011605.34317.jhb>