On Wed, 2008-07-16 at 11:15 -0400, Alan D. Brunelle wrote:
> Martin Peschke wrote:
> > On Wed, 2008-07-16 at 10:47 -0400, Alan D. Brunelle wrote:
> >> Hm, again, if the blktrace | blkiomon (direct, no blkparse) is how you
> >> do things,
> >
> > no, it's blktrace | blkparse | blkiomon
> >
> > Isn't blkparse needed to sort all those per-CPU traces by time?
> > I want this feature.
>
> The traces should come out pretty close from blktrace itself - I'm
> assuming you're interested in putting out statistics in multiples of
> seconds. Perhaps some test cases should be tried, but...
I will give it a try
> ... it certainly seems to me that if one could remove blkparse
> completely you'd save a /tremendous/ amount of CPU
sounds tempting to me
> at the slight cost of
> perhaps having some off-by-a-few counts. (Meaning: You may have a few
> C's that you could not match up with D's (because they come out "later"
> from blktrace).)
I had to make provisions for this case in blkiomon anyway.
I suspect blkparse's batch handling to deliver some C's earlier than the
matching D's. But I have never tracked it down.
Thanks,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrace" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Netdev]
[Linux Wireless]
[Kernel Newbies]
[Memory]
[Security]
[Linux for Hams]
[Netfilter]
[Bugtraq]
[Photo]
[Yosemite]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux RAID]
[Linux Admin]
[Samba]
[Video 4 Linux]
[Linux Resources]