From owner-cvs-src@FreeBSD.ORG Sat Dec 17 19:55:42 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 B994F16A420; Sat, 17 Dec 2005 19:55:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FF3643D64; Sat, 17 Dec 2005 19:55:41 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4018656 for multiple; Sat, 17 Dec 2005 14:53:01 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBHJssIZ000404; Sat, 17 Dec 2005 14:54:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Sat, 17 Dec 2005 14:54:50 -0500 User-Agent: KMail/1.8.3 References: <43A547F2.2090401@root.org> In-Reply-To: <43A547F2.2090401@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200512171454.52514.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1211/Fri Dec 16 17:51:35 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=4.2 tests=ALL_TRUSTED, SUBJ_HAS_SPACES autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 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: Sat, 17 Dec 2005 19:55:43 -0000 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.=20 > >> 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_SUBSY= S=20 but have it optional (I just checked the thread, and in my first e-mail I=20 remembered incorrectly) (i.e. put a #if 0 #define KTR_CRITICAL KTR_CONTENTI= ON=20 #else #define KTR_CRITICAL 0 #endif in kern_switch.c). Given Scott's recen= t=20 changes to schedgraph, it would probably be best to just make then under=20 KTR_SCHED, though maybe have it optional, thus: #if 0 #define KTR_CRITICAL KTR_SCHED #else #define KTR_CRITICAL 0 #endif or something. > 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=20 can be ok to have a KTR class limited to a small number of events if those= =20 events fire very often which these do. I think you can also make KTR_WITNE= SS=20 optional and use KTR_SUBSYS as well. (That's also in my original replies.)= =20 And I'd still be interested in feedback on my proposal to axe the whole=20 bitmask concept for KTR entirely. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org