Messages in this thread | | | Date | Mon, 23 Sep 2002 19:31:40 -0400 | From | Karim Yaghmour <> | Subject | Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure |
| |
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 =================================================== - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |