concept prove patch for ktrace output to all file types
Robert Watson
rwatson at FreeBSD.org
Fri Jun 29 11:00:36 UTC 2007
On Fri, 29 Jun 2007, Howard Su wrote:
> On 6/28/07, Robert Watson <rwatson at freebsd.org> 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
More information about the freebsd-current
mailing list