From: Martin Peschke <mp3@de.ibm.com>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Jens Axboe <jens.axboe@oracle.com>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [Patch 0/5] I/O statistics through request queues
Date: Wed, 25 Oct 2006 00:27:52 +0200 [thread overview]
Message-ID: <453E9368.9070405@de.ibm.com> (raw)
In-Reply-To: <453E79D1.6070703@cfl.rr.com>
Phillip Susi wrote:
> This discussion seems to involve two different solutions to two
> different problems. If it is a simple counter you want to be able to
> poll, then sysfs/debugfs is an appropriate place to make the count
> available. If it is a detailed log of IO requests that you are after,
> then blktrace is appropriate.
It's about counters ... well, sometimes a buch of counters called
histogram.
> I did not read the patch to see, so I must ask: does it merely keep
> statistics or does it log events? If it is just statistics you are
> after, then clearly blktrace is not the appropriate tool to use.
If matters were as simple as that, sigh.
Statistics feed on data reported through events.
"Oh, this request has completed - time to update I/O counters."
The tricky question is: is event processing, that is, statistics data
aggregation, better done later (in user space), or immediately
(in the kernel). Both approaches exist: blktrace/btt vs.
gendisk statistics used by iostat, for example.
My feeling was that the in-kernel counters approach of my patch
was fine with regard to the purpose of these statistics. But blktrace
exists, undeniably, and deserves a closer look.
Martin
next prev parent reply other threads:[~2006-10-24 22:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-21 12:57 [Patch 0/5] I/O statistics through request queues Martin Peschke
2006-10-23 11:37 ` Jens Axboe
2006-10-23 18:11 ` Martin Peschke
2006-10-23 20:02 ` Jens Axboe
2006-10-24 16:02 ` Martin Peschke
2006-10-24 16:20 ` Jens Axboe
2006-10-24 20:38 ` Phillip Susi
2006-10-24 22:27 ` Martin Peschke [this message]
2006-10-25 17:50 ` Frank Ch. Eigler
2006-10-26 11:07 ` Martin Peschke
2006-10-26 12:13 ` Frank Ch. Eigler
2006-10-26 13:37 ` Martin Peschke
2006-10-26 14:02 ` Frank Ch. Eigler
2006-10-26 15:36 ` Martin Peschke
2006-10-26 19:11 ` Frank Ch. Eigler
2006-10-24 23:04 ` Martin Peschke
2006-10-25 5:12 ` Jens Axboe
2006-10-25 10:32 ` Martin Peschke
2006-10-25 10:42 ` Jens Axboe
2006-11-02 14:39 ` martin
2006-11-02 14:46 ` Jens Axboe
2006-10-23 18:39 ` Phillip Susi
2006-10-24 16:05 ` Martin Peschke
2006-10-24 20:44 ` Phillip Susi
2006-10-24 22:49 ` Martin Peschke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=453E9368.9070405@de.ibm.com \
--to=mp3@de.ibm.com \
--cc=akpm@osdl.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=psusi@cfl.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.