From owner-cvs-src@FreeBSD.ORG Sun Dec 18 18:16:24 2005 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07FA316A41F; Sun, 18 Dec 2005 18:16:24 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9697643D5A; Sun, 18 Dec 2005 18:16:21 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id jBIIGKKI004379; Sun, 18 Dec 2005 13:16:20 -0500 X-ORBL: [71.139.30.140] Received: from [10.0.0.115] (ppp-71-139-30-140.dsl.snfc21.pacbell.net [71.139.30.140]) by pimout5-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id jBIIGHGC016230; Sun, 18 Dec 2005 13:16:17 -0500 Message-ID: <43A5A768.4090708@root.org> Date: Sun, 18 Dec 2005 10:16:08 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <43A547F2.2090401@root.org> <200512171454.52514.jhb@freebsd.org> In-Reply-To: <200512171454.52514.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@freebsd.org, Scott Long , src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys ktr.h src/sys/kern kern_clock.c kern_switch.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 18:16:24 -0000 John Baldwin wrote: > On Sunday 18 December 2005 06:28 am, Nate Lawson wrote: > >>Scott Long wrote: >> >>>Nate Lawson wrote: >>> >>>>njl 2005-12-17 03:57:10 UTC >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: >>>> sys/sys ktr.h >>>> sys/kern kern_clock.c kern_switch.c >>>> Log: >>>> Clean up unused or poorly utilized KTR values. Remove KTR_FS, >>>>KTR_KGDB, and KTR_IO as they were never used. Remove KTR_CLK since it >>>>was only used for hardclock firing and use KTR_INTR there instead. >>>>Remove KTR_CRITICAL since it was only used for crit enter/exit and use >>>>KTR_CONTENTION instead. >>>> >>>> Revision Changes Path >>>> 1.183 +1 -1 src/sys/kern/kern_clock.c >>>> 1.118 +2 -2 src/sys/kern/kern_switch.c >>>> 1.35 +12 -12 src/sys/sys/ktr.h >>> >>>Um, I was using KTR_CRITICAL for schedgraph. It was actually quite >>>useful. Compressing the option space only makes the options less >>>useful. Surely there has to be a better solution. Or, at least you >>>could call for comments before you alter this stuff. >> >>You didn't speak up about that in the previous discussion on arch@, >>starting 10/31/2005. The only comment was jhb@ saying it was not useful >>alone, and he's the only one doing work on critical sections lately. > > > I didn't say to merge it to KTR_CONTENTION, I said to make it use KTR_SUBSYS > but have it optional (I just checked the thread, and in my first e-mail I > remembered incorrectly) (i.e. put a #if 0 #define KTR_CRITICAL KTR_CONTENTION > #else #define KTR_CRITICAL 0 #endif in kern_switch.c). Given Scott's recent > changes to schedgraph, it would probably be best to just make then under > KTR_SCHED, though maybe have it optional, thus: > > #if 0 > #define KTR_CRITICAL KTR_SCHED > #else > #define KTR_CRITICAL 0 > #endif > > or something. Ok, I committed this. >>If you can think of another use for this besides one event (enter/exit), >>feel free to add it back. Or, consider adding KTR_SUBSYS as a one-off >>use like KTR_DEV is for other parts of the system. KTR_CRITICAL would >>be conditionally defined as KTR_SUBSYS when needed. > > > That's what I asked you to do and you ignored that part of what I said. :( It > can be ok to have a KTR class limited to a small number of events if those > events fire very often which these do. I think you can also make KTR_WITNESS > optional and use KTR_SUBSYS as well. (That's also in my original replies.) > And I'd still be interested in feedback on my proposal to axe the whole > bitmask concept for KTR entirely. I didn't want to add KTR_SUBSYS or touch KTR_WITNESS when I wasn't sure of all the ramifications. I've got enough free bits now; feel free to continue this if you want. -- Nate