Re: concept prove patch for ktrace output to all file types

On Fri, 29 Jun 2007, Howard Su wrote:

On 6/28/07, Robert Watson <rwatson@xxxxxxxxxxx> wrote:

What happens to processes associated with the same or other ktrace sessions if one ktrace session stalls due to a fifo or pipe buffer filling?

I don't think my patch will bring the new problem here. Original, we write to disk still be blocked due to some things like disk busy, etc.

If my reading is right, ktrace use two way to submit request. ktr_enqueue will put the request into a queue if it is not safe to enter VFS. ktr_submitrequest will be used to commit record to disk immediately. in my case, blocking will be safe there.

The issue about losting some recording to fifo blocking. I don't think we can solve that in the kernel. It is userland code's responsiblity to read it to avoid losting data.

The question I'm asking is most interesting with respect to independent ktrace sessions, potentially associated with different users. If a tracing app can't keep up with the app it's tracing, that's quite a different case from all system tracing breaking because one tracing app can't keep up with its particular target. In a casual analysis, it looks like if one fifo blocks, then all tracing across the system is stuck waiting on that fifo to unblock?

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"