Re: KTR changes

From: Nate Lawson (nate_at_root.org)
Date: 11/01/05

  • Next message: Nate Lawson: "Re: KTR changes" 
    Date: Tue, 01 Nov 2005 12:25:02 -0800
To: John Baldwin <jhb@FreeBSD.org>

    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?

    >> As such, I'd like to mark the following unused and free for allocation:
    >> KTR_NET, KTR_FS, KTR_MALLOC, KTR_KGDB, KTR_IO
    >
    > I'd rather someone add KTR_MALLOC traces than get rid of
    > it. :) If we fleshed out our more general logging for
    > in-kernel facilities that helps to get a general feel of what
    > the system is doing when debugging. I think some traces are
    > for debugging specific subsystems such as KTR_WITNESS or
    > KTR_TULIP where as some are more general to tell you what the
    > kernel is doing (KTR_PROC, KTR_INTR, and KTR_LOCK fall into
    > this category as probably would KTR_MALLOC and KTR_CONTENTION).
    > I think subsystem trace classes should be mapped to generic
    > bits where as kernel-wide tracing should get their own bits if
    > possible.

    So since no one defended KTR_FS, KGDB, and IO, I'll reclaim those. I'm
    out of bits and need one for KTR_POWER.

    >> These should be merged the following under KTR_MALLOC (KTR_MEM?):
    >> KTR_UMA: uma_zalloc_arg, uma_zfree_arg
    >> KTR_VM: vmspace_alloc, vmspace_free, vm_map_create, vm_map_entry_unlink
    >
    > Well, I'm not sure about those as the KTR_VM ones aren't related
    > to kernel malloc at all. vmspaces are the user virtual address
    > mappings with vm_map being individual mappings. :) That's like
    > saying that mmap() should be part of malloc(). :) I also think
    > KTR_UMA is probably useful for getting a general feel for memory
    > allocation activity in the kernel.

    What I'm trying to achieve is a general "KTR_MEMORY_STUFF" key. If
    you're interested in allocations, getting info about mappings wouldn't
    hurt either.

    >> Merge under KTR_SYNCH (KTR_LOCK?):
    >> KTR_CRITICAL: critical enter/exit
    >> KTR_CONTENTION: mutex contention start/end
    >
    > Perhaps default KTR_CRITICAL to off and let people who want it
    > map it to a generic bit. It's very expensive and I'm not sure
    > it's very useful for all but a few people. Then I would leave
    > KTR_CONTENTION alone.

    Ok, so KTR_CRITICAL can be reclaimed also.

    >> Merge under KTR_TIMER:
    >> KTR_CLK: hard clock firing
    >
    > KTR_CLK is useless, just drop it. Instead, maybe add KTR_INTR
    > traces for clock interrupts where they are missing.

    Ok.

    > I don't think anyone uses KTR_CTx currently?
    >
    >> Last, I'd like to add a new level, KTR_POWER, for use with power
    >> management events. Since we only have 32 bits of KTR levels, it's
    >> important to use them carefully. Comments on all this are welcome.
    >
    > Is this for debugging stuff inside ACPI or is it supposed to record
    > general system-wide activity?

    System-wide power activity. Devices being powered up or down,
    suspend/resume methods, ACPI control of mosfets, etc.

    > 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? 

    -- 
Nate
_______________________________________________
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: Nate Lawson: "Re: KTR changes"

    Relevant Pages

    • Re: KTR changes
      ... the system is doing when debugging. ... I think some traces are ... to kernel malloc at all. ... map it to a generic bit. ...
      (freebsd-arch)
    • Re: [RFC/PATCH] Documentation of kernel messages
      ... On Fri, 15 Jun 2007 11:51:51 PDT, Randy Dunlap wrote: ... And "for debugging" doesn't cut it IMO. ... people doing support can annotate the messages with real life experience on ... Providing a means for getting localized kernel ...
      (Linux-Kernel)
    • RE: VMWare Workstation 6 for debugging Linux Kernel (!)
      ... maybe somebody make some side by side comparison of vmware & uml regarding kernel debugging. ... Run gdb on the Host, reference it to the kernel with symbols and attach to ...
      (Linux-Kernel)
    • Re: driver probe error reporting
      ... on probe. ... errors that are due to configuration such as missing device configuration ... data error is a bloat of code as a properly debugged kernel should never ... recently I've been debugging suspend-resume quite a lot and I had to ...
      (Linux-Kernel)
    • Re: 6.x hangs on AMD64 again
      ... debugging to figure out the cause. ... debugging the developers handbook; without this information no ... That is indeed almost always failing hardware. ... I compiled the kernel with debug info, but that's totally useless, since it won't dump anything, just hang there; I don't think even DDB would help, since even the keyboard is not working at that time. ...
      (freebsd-questions)