KTR changes

[Nate Lawson]

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