by Thomas Gleixner

[permalink] [raw]

Subject: [RFC] Instrumentation (was Re: 2.6.11-rc1-mm1)

</Flame off>

On Fri, 2005-01-14 at 15:22 -0800, Tim Bird wrote:
> but not 1) supporting infrastructure for timestamping, managing event
> data, etc., and 2) a static list of generally useful tracepoints.

Both points are well taken. Thats the essential minimum what
instrumentation needs.

I'd like to see this infrastructure usable for all kinds of
instrumentation mechanisms which are built in to the kernel already or
functions which are used for similar purposes in experimental trees and
other instrumentation related projects.

This requires to seperate the backend from the infrastructure, so you
can chose from a set of backends which fit best for the intended use.

One of those backends is LTT+relayfs.
I really respect the work you have done there, but please accept that I
just see the limitations and try to figure out a way to make it more
generic and flexible before it is cemented into the kernel and makes it
hard to use for other interesting instrumentation aspects and maybe
enforces redundant implementation of infrastructure related
functionality.

E.g. tracking down timing related issues can make use from such
functionality if the infrastructure is provided seperately.
I guess a lot of developers would be happy to use it when it is already
around in the kernel and it can help testers for giving better
information to developers.

tglx

2005-01-16 00:59:51

Karim Yaghmour writes:
>
> What I'm dropping for now is all the functions that allow a
> subsystem to read from a channel from within the kernel. So,
> for example, if you want to obtain large amounts of data from
> user-space via a relayfs channel you won't be able to. Here
> are the functions that would go:
>
> rchan_reader *add_rchan_reader(channel_id, auto_consume)
> int remove_rchan_reader(rchan_reader *reader)
> rchan_reader *add_map_reader(channel_id)
> int remove_map_reader(rchan_reader *reader)
> int relay_read(reader, buf, count, wait, *actual_read_offset)
> void relay_buffers_consumed(reader, buffers_consumed)
> void relay_bytes_consumed(reader, bytes_consumed, read_offset)
> int relay_bytes_avail(reader)
> int rchan_full(reader)
> int rchan_empty(reader)
>
> We could add these at a later time when/if needed. Removing
> these changes nothing for ltt.

One of the things that uses these functions to read from a channel
from within the kernel is the relayfs code that implements read(2), so
taking them away means you wouldn't be able to use read() on a relayfs
file. That wouldn't matter for ltt since it mmaps the file, but there
are existing users of relayfs that do use relayfs this way. In fact,
most of the bug reports I've gotten are from people using it in this
mode. That doesn't mean though that it's necessarily the right thing
for relayfs or these users to be doing if they have suitable
alternatives for passing lower-volume messages in this way. As others
have mentioned, that seems to be the major question - should relayfs
concentrate on being solely a high-speed data relay mechanism or
should it try to be more, as it currently is implemented? If the
former, then I wonder if you need a filesystem at all - all you have
is a collection of mmappable buffers and the only thing the filesystem
provides is the namespace. Removing read()/write() and filesystem
support would of course greatly simplify the code; I'd like to hear
from any existing users though and see what they'd be missing.

ltt would still need at least relay_buffers_consumed() though. This
is used to support the 'no-overwrite' option, which means that when
the buffers are full i.e. the daemon has fallen behind and needs to
catch up, channel writing is 'suspended' until it catches up.

>
> Also, we should try to get rid of the following. They are there
> for allowing dynamically-resizable buffers, but if we are to
> make buffer-management opaque, then this should be done
> internally (Tom: I can't remember the rationale for these. Let
> me know if there's a reason why the must be kept.)
>
> int relay_realloc_buffer(*rchan, nbufs, async)
> int relay_replace_buffer(*rchan)

relay_realloc_buffer actually does the work of allocating the new
buffer space for used for resizing, and since it can sleep, it's done
in the background using a work queue. When everything's ready, the
channel buffer can then be replaced, thus relay_replace_buffer().

The only user of channel resizing that I know of is the 'dynamically
resizeable printk replacement' I posted awhile back, and that
apparently doesn't have any users, so I'd be happy to get rid of all
the resizing code.

Tom

>
> I think this is a pretty major change and simplification of the
> API along the lines of what others have asked for. Let me know
> what you think.
>
> Karim
> --
> Author, Speaker, Developer, Consultant
> Pushing Embedded and Real-Time Linux Systems Beyond the Limits
> http://www.opersys.com || [email protected] || 1-866-677-4546

--
Regards,

Tom Zanussi <[email protected]>
IBM Linux Technology Center/RAS

2005-01-16 18:46:54

On Mon, 2005-01-17 at 15:34 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > Thats the point. Adding another hardwired implementation does not give
> > us a possibility to solve the hardwired problem of the already available
> > stuff.
>
> Well then, like I said before, you know what you need to do:
> http://www-124.ibm.com/developerworks/oss/linux/projects/kernelhooks/

Oh, I guess my English must be really bad.

I was talking about seperation of layers, so why do I need
kernelhooks ?

The seperation of layers makes it possible to actually reuse
functionality and gives the possibility that existing hardwired stuff
can be cleaned up to use the new functionality too.

If we add another hardwired implementation then we do not have said
benefits.

tglx

2005-01-17 23:36:25

Roman Zippel wrote:
> Ok, great.
> BTW I don't really expect the first version to be fully optimized (unless
> you want to :) ), but once the basics are right, that can still be added
> later.

Agreed. Tom will post updated patches sometime this week. I'll follow up
with the LTT stuff separately as agreed.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [email protected] || 1-866-677-4546