From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 20:25:48 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 089C216A41F; Tue, 1 Nov 2005 20:25:48 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A643443D45; Tue, 1 Nov 2005 20:25:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jA1KPkxq006217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Nov 2005 12:25:46 -0800 Message-ID: <4367CF1E.2020809@root.org> Date: Tue, 01 Nov 2005 12:25:02 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4366999B.4070005@root.org> <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> In-Reply-To: <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 20:25:48 -0000 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