linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Peschke <mp3@de.ibm.com>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [Patch 0/5] I/O statistics through request queues
Date: Tue, 24 Oct 2006 18:05:04 +0200	[thread overview]
Message-ID: <453E39B0.2000800@de.ibm.com> (raw)
In-Reply-To: <453D0C62.4030601@cfl.rr.com>

Well, the instrumentation "on demand" aspect is half of the truth.
A probe inserted through kprobes impacts performance more than static
instrumentation.


Phillip Susi wrote:
> 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
>>
> 




  reply	other threads:[~2006-10-24 16:05 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
2006-10-24 16:05   ` Martin Peschke [this message]
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=453E39B0.2000800@de.ibm.com \
    --to=mp3@de.ibm.com \
    --cc=akpm@osdl.org \
    --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 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).