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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |