On Thu, Oct 04, 2007 at 12:19:35PM -0700, David Wilder wrote:Andi Kleen wrote:"David J. Wilder" <dwilder@xxxxxxxxxx> writes:The code in trace is exactly what all the current users of relay do. Therefor trace reduces the duplication of code.@@ -0,0 +1,160 @@Wasn't relayfs supposed to do that already? Why do you need another
+Trace Setup and Control
+In the kernel, the trace interface provides a simple mechanism for
+starting and managing data channels (traces) to user space.
wrapper around it?
If everybody does this then the code should be just put into
Is this also really still faster than a printk below log levelAre you arguing against relayfs or trace? Trace just makes relayfs easer to use. I think relayfs can stand up for it's self.
(without console driver overhead). If not then why not just
I'm arguing against complicated trace mechanisms that are not fast.
over head per call roughtly like putchar()),
At some point when I looked at relayfs it seemed to be reasonably
fast (per cpu buffers; not much locking,
but that might have regressed.
Your example module with its lock definitely looks very slow and I don't approve
The example shows a way to create an ASCII data layer.
ASCII layers don't make much sense imho -- these should just use printk.
Fast dedicated binary log channels make sense though; but you don't
seem really to be very concentrated on that.
True, to make trace "fast" you need a data layer that can handle the requirements of per-cpu buffers. However there are still advantages of trace over printk even when using global bufferers: selectable bufferer sizes,
printk has selectable buffer sizes too.
"Long term we probably want more complex tracing based on lttng,
but I'm a big fan of starting out simple and doing incremental
It's just that relayfs + another not simple layer are definitely not simple.
For a simple logger I'm thinking more like something like SGI's old
ktrace module (which undoubtedly many other people have recreated many
times for specific debugging scenarios)
But that all only makes sense if the overhead is really kept low
and i don't see that in your approach.
One advantage of the trace approach is separating control and data layers, therefor trace can support multiple data layers to fit multiple requirements.
I have my ideas on how to develop data layer, others may have their own ideas and I welcome the input.
relayfs was supposed to be that data layer.
PS: Systemtap has been criticized for introducing out-of-tree kernel code. A clear direction from the community is to move re-usable code in-tree where it can be maintained. Trace is a move in that direction.
I'm all for that. I believe a simple fast efficient no frills logger
would serve systemtap just fine too. But the approach here seems
to be more to add all kinds of knobs and whizzles until you end
up with something as slow with printk. And since we already have
printk another one just doesn't seem to make much sense.