Re: [Patch 0/5] I/O statistics through request queues

[Jens Axboe <jens.axboe@oracle.com>]

On Wed, Oct 25 2006, Martin Peschke wrote:
> Jens Axboe wrote:
> >>>Thanks! Also note that you do not need to log every event, just register
> >>>a mask of interesting ones to decrease the output logging rate. We could
> >>>so with some better setup for that though, but at least you should be
> >>>able to filter out some unwanted events.
> >>...and consequently try to scale down relay buffers, reducing the risk of
> >>memory constraints caused by blktrace activation.
> >
> >Pretty pointless, unless you are tracing lots of disks. 4x128kb gone
> >wont be a showstopper for anyone.
> 
> per (online) CPU and device?

Yes, per device and per CPU. It does add up of course, but even some
megabytes of buffers should be ok for most uses. You can shrink them, if
you don't need that much. It is advised to have at least two sub-buffers
though, so shrinking the size is probably better.

> >>>>However, a fast network connection plus a second system for blktrace
> >>>>data processing are serious requirements. Think of servers secured
> >>>>by firewalls. Reading some counters in debugfs, sysfs or whatever
> >>>>might be more appropriate for some one who has noticed an unexpected
> >>>>I/O slowdown and needs directions for further investigation.
> >>>It's hard to make something that will suit everybody. Maintaining some
> >>>counters in sysfs is of course less expensive when your POV is cpu
> >>>cycles.
> >>Counters are also cheaper with regard to memory consumption. Counters
> >>are probably cause less side effects, but are less flexible than
> >>full-blown traces.
> >
> >And the counters are special cases and extremely inflexible.
> 
> Well, I disagree with "extremely".

Fairly inflexible, then :-)

> These statistics have attributes that allow users to adjust data
> aggregation, e.g. to retain more detail in a histogram by adding
> buckets.

I'm not saying they aren't useful, just saying that their are mainly
useful for dasd apparently.

Lets let this go until we know more about how to proceed.

-- 
Jens Axboe