From owner-svn-src-all@FreeBSD.ORG Mon Mar 2 21:44:24 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7372B6EE; Mon, 2 Mar 2015 21:44:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47D43C40; Mon, 2 Mar 2015 21:44:24 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 42773B915; Mon, 2 Mar 2015 16:44:23 -0500 (EST) From: John Baldwin To: Davide Italiano Subject: Re: svn commit: r279539 - head/sys/sys Date: Mon, 02 Mar 2015 16:43:13 -0500 Message-ID: <6289045.RUKNCQ1AEg@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <201503022005.t22K5HTL062907@svn.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 02 Mar 2015 16:44:23 -0500 (EST) Cc: John-Mark Gurney , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 21:44:24 -0000 On Monday, March 02, 2015 12:26:46 PM Davide Italiano wrote: > On Mon, Mar 2, 2015 at 12:05 PM, John-Mark Gurney wrote: > > Author: jmg > > Date: Mon Mar 2 20:05:16 2015 > > New Revision: 279539 > > URL: https://svnweb.freebsd.org/changeset/base/279539 > > > > Log: > > give others fair warning that _SPARE2 isn't just cxgb, but used by large > > number of other subsystems, so you probably don't want _SPARE2.. > > > > ktr needs an overhaul to really only compile in the ones you want, > > we've long passed the 31 bits it provides.. > > If you really want to do the overhaul (which would be honestly great), > I might consider revamping my work for per-cpu KTR buffer and include > that in the change. Originally it was just an exercise, but then it > evolved and I've been sitting with it in my local tree for a while. I > never had the chutzpah to upstream it because it involves fundamental > changes and breaks compatibility with the old ktrdump(1) format. > A rather outdated (and maybe not completely functional) version of the > patch can be found here: > http://people.freebsd.org/~davide/locking/ktr_percpu.4.diff , which > should give you an high level view of the change. > I can update it to the last version and bring up for review, if > somebody think it might be a sane idea avoiding synchronization on a > single buffer for KTR. The only issue with that is that often when I use KTR I want to see the "true" order of operations between CPUs. I realize it is a tradeoff between the extra synchrony in KTR "fixing" some races while you are debugging vs having misleading traces that don't let you line up events to know what occurred when. For replacing the mask field, I've kicked around in my head a replacement for ktr_mask that would use per-type integers, so you would have debug.ktr.proc tunables and sysctls. There are some downsides to this though. In the past I've used hacks where I would clear ktr_mask when certain events happen so that I could reliably get a trace of events leading up to a specific event that wasn't itself a crash. Having N different integers is not conducive to that, though could perhaps have a global "ktr_enabled" to give that. What I was stuck on before was getting the cpp macro glue nice so that one could ideally use the existing CTRx() macros without having to redo all of them. Was thinking of having something like 'KTR_DECLARE(KTR_PROC)' and 'KTR_DEFINE(KTR_PROC, "some description")', etc. You might end up with ktr_type_## type variables and CTRx() would check those. However, that doesn't support KTR_COMPILE at all (and I hadn't worked out a way to do that cleanly, though we could also just punt and always compile in all traces). It also doesn't easily support CTRx(KTR_FOO | KTR_BAR, ...) which does occur a few places in the tree, though we could possibly just replace those with duplicates. -- John Baldwin