Messages in this thread | | | Date | Wed, 13 Jul 2005 08:56:45 -0700 | From | Vara Prasad <> | Subject | Re: Merging relayfs? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |