ktrace and KTR_DROP

[Peter Wemm]

On Friday 01 July 2005 08:04 am, Robert Watson wrote:
> On Fri, 1 Jul 2005, Peter Edwards wrote:
> > Ever since the introduction of a separate ktrace worker thread for
> > writing output, there's the distinct possibility that ktrace output
> > will drop requests. For some proceses, it's actually inevitable: as
> > long as the traced processes can sustain a rate of generating
> > ktrace events faster than the ktrace thread can write them, you'll
> > eventually run out of ktrace requests.
[..]
> One of the things I've been thinking for a few years is that I think
> I actually preferred the old model better, there processes (now
> threads) would hang a "current record" off of their process (now
> thread) structure, and fill it in as they went along. 

I much prefer the old model as well.  I personally would like to have 
syscall returns delayed if the outstanding writes for ktrace requests 
is above a certain watermark.  There have been several suggestions for 
how to do this.

This could be as simple as throttling *all* ktrace writers as they 
return to userland from syscalls if the backlog is getting too large.  
But probably better would be to have each process responsible for its 
own writing and backlog management.  ie: queue up the records to memory 
just like now, and start unwinding them at a convenient location in 
syscall return.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5