Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure

[Karim Yaghmour <karim@opersys.com>]

Andreas Ferber wrote:
> Fairly simple to achieve: provide some sort of userspace trace daemon
> from which the users request the trace events they want to see
> (communicating through standard IPC channels). The daemon provides a
> unified event mask to the kernel (to prevent unnecessary overhead in
> the kernel proper) and dispatches the events read from the kernel.

This, though, is the rather simple scenario. What would you do with
events generated by a user-space application and for which the daemon
has no idea of the format? What if there are five such applications
running in parallel each asking for its own separate buffer? What
about the telco guys at the RAS BoF (any many others for that matter)
that want to have a flight recorder (i.e. you always keep one buffer
going ALL the time and you only check it when something bad happens)?
There really needs to be a way to handle multiple input and output
streams. Fortunately, nontheless, our preliminary work on this issue
indicates that the overhead is minimal (i.e. add a "channel ID" to
each event; the tracer then uses the ID to put the event in the right
buffer; no filtering at this level).

> You will have to record uid/gid/pid/whatever criteria you might think
> of with the event, somewhat enlarging (by a few bytes) a single event
> record (don't know how much of this data you are currently gathering),
> but that is a minor tradeoff IMHO.

Minimizing event size is pretty high on the list of priorities. A few
bytes more per event makes a huge difference when you know that there
are above 10,000 events per second for a middle to low speed machine.

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================