svn commit: r279539 - head/sys/sys

[John Baldwin]

On Monday, March 02, 2015 12:26:46 PM Davide Italiano wrote:
> On Mon, Mar 2, 2015 at 12:05 PM, John-Mark Gurney <jmg at freebsd.org> 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