linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Martin Peschke <mp3@de.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [Patch 0/5] I/O statistics through request queues
Date: Mon, 23 Oct 2006 14:39:30 -0400	[thread overview]
Message-ID: <453D0C62.4030601@cfl.rr.com> (raw)
In-Reply-To: <1161435423.3054.111.camel@dyn-9-152-230-71.boeblingen.de.ibm.com>

Would this be a good candidate to implement using kprobes?  I was under 
the impression that basing instrumentation on kprobes would be a good 
thing since you can load the instrumentation code only when needed, then 
unload it.

Martin Peschke wrote:
> This patch set makes the block layer maintain statistics for request
> queues. Resulting data closely resembles the actual I/O traffic to a
> device, as the block layer takes hints from block device drivers when a
> request is being issued as well as when it is about to complete.
> 
> It is crucial (for us) to be able to look at such kernel level data in
> case of customer situations. It allows us to determine what kind of
> requests might be involved in performance situations. This information
> helps to understand whether one faces a device issue or a Linux issue.
> Not being able to tap into performance data is regarded as a big minus
> by some enterprise customers, who are reluctant to use Linux SCSI
> support or Linux.
> 
> Statistics data includes:
> - request sizes (read + write),
> - residual bytes of partially completed requests (read + write),
> - request latencies (read + write),
> - request retries (read + write),
> - request concurrency,
> 
> For sample data please have a look at the SCSI stack patch or the DASD
> driver patch respectively. This data is only gathered if statistics have
> been enabled by users at run time (default is off).
> 
> The advantage of instrumenting request queues is that we can cover a
> broad range of devices, including SCSI tape devices.
> Having the block layer maintain such statistics on behalf of drivers
> provides for comparability through a common set of statistics.
> 
> A previous approach was to put all the code into the SCSI stack:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=115928678420835&w=2
> I gathered from feedback that moving that stuff to the block layer
> might be preferable.
> 
> These patches use the statistics component described in
> Documentation/statistics.txt.
> 
> Patches are against 2.6.19-rc2-mm2.
> 
> [Patch 1/5] I/O statistics through request queues: timeval_to_us()
> [Patch 2/5] I/O statistics through request queues: queue instrumentation
> [Patch 3/5] I/O statistics through request queues: small SCSI cleanup
> [Patch 4/5] I/O statistics through request queues: SCSI
> [Patch 5/5] I/O statistics through request queues: DASD
> 
> Martin
> 


  parent reply	other threads:[~2006-10-23 18:39 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
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 [this message]
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=453D0C62.4030601@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mp3@de.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).