All of lore.kernel.org
 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 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.