Re: KTR changes

From: John Baldwin (jhb_at_freebsd.org)
Date: 11/01/05

  • Next message: Robert Watson: "Re: KTR changes" 
    To: Nate Lawson <nate@root.org>
Date: Tue, 1 Nov 2005 16:05:33 -0500

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Robert Watson: "Re: KTR changes"