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


Vara Prasad writes:
 > 
 > As we discussed on the call two weeks back for supporting debugging and=20
 > performance
 > analysis goals of systemtap we need a high speed and low overhead=20
 > transport mechanism.
 > Relayfs specifically designed for this purpose. Now that it has gone=20
 > through community
 > review and on it's way to mainline we should definitely consider that. =20
 > I agree
 > that we should not invent a new filesystem for this, but we should make
 > enhancements if needed to the existing ones.
 > 

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.

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) - the only way to get data from the
channel to user space is mmap(), so it means data will become ready
and be read in 'blocks' of data the same size as the 'sub-buffer'
size.  I don't know if this maps well to systemtap's needs for a
generic transport/messaging mechanism but could well be useful for the
high-speed tracing part of it.  I don't know either if you should be
assuming that we can just add parts of the old relayfs back into the
new version - there was a considerable amount of discussion on lkml
about the relayfs API and what relayfs should be, the result being
what's in the -mm tree now - adding things back in would be moving
away from the 'do one thing and do it well' goal and towards the old
relayfs which has already been rejected for trying to do too much.

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.

Tom





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