Re: Merging relayfs?

[Vara Prasad]

Tomasz Kłoczko wrote:

> On Tue, 12 Jul 2005, Vara Prasad wrote:
> [..]
[..]

> If I can suggest something about order prepare some feactures:
>
> 1) prepare base infrastructure for counters,
>
> this "tool" will take very small amount of data and can be performad
> by very small pieces of binary codes. Even this will allow perform some
> *very* interesting experinments on existing kernel code.
> And after above:
>
> 2) prepare base infrastructure for association tables of couters (for
>    collecting data for example about I/O operations or other two or more
>    arguments operations),
> 3) prepare user space tool with some kind of language which will allow
>    hanging ptrobes with aboove tho (simple counters and association 
> tables
>    of couters)
> 4) base functions for measure time (with KProbes overhead and without) 
> and
>    store them in couters and association tables,
>
> All above base "tools" for above will take small or medium amount of 
> data and can be performad small or medium pieces of binary codes. And 
> after above:
>
> 5) prepare infrastrucrute for probes which will store data in diffrent
>    containers depending on initiator process and/or thread (and maybe in
>    next etap also will be good have something more common which will
>    depend on stack path),
> 6) prepare base functions for tracing stack paths (counting them and 
> store
>    in association tables),
> 7) make some kind of study where is it will be good compute something
>    more complicated like base "speculative probes" (lookin on
>    working DTrace probably answer in this point will be "yes").
Looks like you have not looked at systemtap project although Tom pointed 
about it to you in his previous postings.  The URL for systemtap is 
http://sourceware.org/systemtap/, i strongly suggest you to look at that 
project.  We are implementing most of the above what you are suggesting 
in the systemtap project. I don't agree with you that implementing the 
above features is trivial and takes small amount of code, can you submit 
patches to show the simple implementation you are talking about.

> All to this moment will not require relayfs because amount of transfered
> data will be _very low_.

I think you are forgetting the fact that relayfs has two different 
portions one is the buffering scheme another is the data transfer 
mechanism. Some of the above features you are talking of needs a 
buffering scheme.

> Details of above will be probably different (I have only some very 
> common knowledge about DTrace implementations details and some 
> avarange about using dtrace tool) but I want count/pint *only* 
> feactutres which will not require using relayfs.

I beg to differ, as i mentioned in my earlier postings Dtrace has a 
similar per-CPU buffering scheme according to their USENIX paper 
http://www.sun.com/bigadmin/content/dtrace/dtrace_usenix.pdf refer to 
section 3.3, can you explain why?

[...]

> But if you will build all infrastructure even for simple couters on 
> relayfs fundament it will be (IMO) badly/incorrectly designed .. and 
> using
> even simple couters will introduce to high overhead for system.

Do you have any performance data to justify your claim of high overhead?

[...]

> regards
>
> kloczek

bye,
Vara Prasad

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/