From owner-freebsd-arch@FreeBSD.ORG Thu Jun 7 20:47:29 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 74E22106566B; Thu, 7 Jun 2012 20:47:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3BE3D8FC14; Thu, 7 Jun 2012 20:47:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A2522B948; Thu, 7 Jun 2012 16:47:28 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 7 Jun 2012 16:42:41 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <86bokyvtc2.fsf@ds4.des.no> <20120607220933.00003865@unknown> In-Reply-To: <20120607220933.00003865@unknown> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206071642.41216.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 07 Jun 2012 16:47:28 -0400 (EDT) Cc: Attilio Rao , Alexander Leidinger , Adrian Chadd , Dag-Erling@freebsd.org, grav Subject: Re: KTR_SPAREx 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: Thu, 07 Jun 2012 20:47:29 -0000 On Thursday, June 07, 2012 4:09:33 pm Alexander Leidinger wrote: > On Tue, 5 Jun 2012 21:14:02 +0100 Attilio Rao > wrote: > > > 2012/6/5 Adrian Chadd : > > > Hi, > > > > > > I'm very tempted to make if_ath use KTR_DEV, but then have an extra > > > ath sysctl which does something like: > > > > > > if (sc->sc_ktr_enable) > > > KTR(); > > > > But the actual problem is that your output will be overwhelmed by the > > clutter of all the other KTR_DEV consumers. > > > > We very much need an much higher granularity on KTR classes and > > possibly a way to use it on-the-fly for kernel development and I think > > what I suggested earlier makes sense. > > How much of the uncovered uses of KTR really need KTR (instead of > dtrace)? How many of them are time critical enough that dtrace is not > fast enough? How many of them need to run very early so that not enough > kernel infrastructure is available to run dtrace (can we run dtrace > scripts very early during boot (when enough kernel infrastructure is > available, before anything in userland starts) like in Solaris)? Can you run a dtrace script from ddb? (Hint: you can run 'show ktr' from DDB, and you can use ktrdump on a crash dump to get a timeline of events when doing post-mortem analysis.) -- John Baldwin