This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with netlink needed


On Thu, 2005-03-31 at 10:57 -0600, Tom Zanussi wrote:

> As I've also discussed with you, Vara, and mentioned a couple times on
> this list, it might make sense to consider relayfs as one part of the
> equation, namely the high-speed tracing part, but I don't know that it
> makes sense as a general-purpose transport.

I am looking at it more closely, trying to determine that too.

I am also concerned about building relayfs.  Can it be built separately,
or will existing Red Hat kernels need to be patched and rebuilt?

> As you know, relayfs recently underwent a massive overhaul in order
> for it to be considered for inclusion, with the goal being to 'do one
> thing and do it well'.  A couple of examples of the changes that were
> made to support this: each channel is hard-coded to create a set of
> per-CPU buffers - there is no way to create a single-buffer channel -
> ,and removing support for read(2) - 

One thing I have been debating is the value of per-cpu vs single
buffers.  Per-cpu buffers have a performance advantage, but for simple
probes it will be annoying to reconstruct the output moving around
through many different buffers. For profiling, per-cpu buffers are
ideal.

> I guess the challenge for systemtap is to figure out how to seamlessly
> integrate and make use of the strengths of the different kernel<->user
> mechanisms that already exist in support of the different systemtap
> requirements.

Yesterday I got basic netlink transport working. I expect I'll play
around with that for a while then try using relayfs in addition to
netlink.  

Martin



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]