Date: Mon, 31 Oct 2005 20:23:45 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: arch@FreeBSD.org Subject: Re: KTR changes Message-ID: <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> In-Reply-To: <4366999B.4070005@root.org> References: <4366999B.4070005@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181>