Re: KTR changes

• Previous message: Nate Lawson: "KTR changes"
• In reply to: Nate Lawson: "KTR changes"
• Next in thread: Frank Mayhar: "Re: KTR changes"
• Reply: Frank Mayhar: "Re: KTR changes"
• Reply: Nate Lawson: "Re: KTR changes"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Mon, 31 Oct 2005 20:23:45 -0500
To: Nate Lawson <nate@root.org>

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.

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

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

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

> KTR_CALLOUT: Giant or mutex-based callout run

Then you can leave KTR_CALLOUT as is. :)

> Also, it appears that we overran into KTR_CTx space with KTR_UMA
> (rwatson). Is this something that needs to be changed or should we
> reduce KTR_CTx?

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?

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.

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

• Previous message: Nate Lawson: "KTR changes"
• In reply to: Nate Lawson: "KTR changes"
• Next in thread: Frank Mayhar: "Re: KTR changes"
• Reply: Frank Mayhar: "Re: KTR changes"
• Reply: Nate Lawson: "Re: KTR changes"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]