Re: Merging relayfs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 12 Jul 2005, Tom Zanussi wrote:
[..]
> DTrace real examples shows something completly diffret.
> MANY things (if not ~almost all) can be kept only in aggregated form
> during experiments.

But you can also do the aggregation in user space if you have a cheap
way of getting it there, as we've shown with some of the examples.

Sorry but real life examples shows that store chunk of data in agregator is less expensive than context switch neccessary for store data or time neccasy for send and handle signal from buffer like "I'm full! let me out of here ..".

[..]
> store raw data. What you need ? only one counter (few bytes) instead of huge
> amount of memeory for buffer and store logs. Try measure something like
> scheduler with possible small system distruption.

Most of the time the data is just being buffered and only when the
buffer is full is it written to disk, as one write.  If that's too
disruptive, then maybe you do need to do some aggregation in the kernel,
but it sounds like a special case.

OK .. "so you can say better is stop flushing buffers on measure which wil take day or more" ? :_) Some DTrace probes/technik are specialy prepared for long or evel very long time experiment wich will only prodyce few lines results on end of experiment.
Look at DTrace documentation for speculative tracing:
http://docs.sun.com/app/docs/doc/817-6223/6mlkidli7?a=view

Some experiments do not have deterinistic time and must be finished after i. e. "occasional failing". What if it will take so long so you will fill all avalaible storage in relayfs way ? OK, never mind .. you have discontinued storage. Using kind speculative tracing way I'll have result *just after* "occasional failing" and you will start parse data stored using relayfs.

kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*

[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]
  Powered by Linux