public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Martin Devera <devik@cdi.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: wrong in_flight diskstat in 2.6.16.1
Date: Tue, 23 May 2006 11:23:24 +0200	[thread overview]
Message-ID: <20060523092324.GO26261@suse.de> (raw)
In-Reply-To: <4472CD62.5060906@cdi.cz>

On Tue, May 23 2006, Martin Devera wrote:
> Hello,
> 
> I see weird output from /sys/block/sd{a,b}/stat on our AMD64-X2 smp 
> machine with HT1000 (Broadcom) SATA with 2 WD 250GB HDDs in MD raid1. AS 
> scheduler was used, change to noop didn't change anything. It is vanilla 
> 2.6.16.1 and here are absolute values in hex and one second differences 
> below:
> 
> 132CDF 56D62 61753C0 6966BC 165A8EB 5FF5B6C 3B32D6C0 1110594C FFCA89A4 
> FEE85878 49FF74E4
> 132CDF 56D62 61753C0 6966BC 165A8EF 5FF5B6C 3B32D6E0 111059D0 FFCA89A1 
> FEE85C60 79291244
>  0: 0
>  1: 0
>  2: 0
>  3: 0
>  4: 4
>  5: 0
>  6: 32
>  7: 132
>  8: -3
>  9: 1000
> 10: 791256416
> 
> As you can see in_flight is constantly negative and it is DECREASING 
> slowly all the time.
> I can't find any reason for it :-\

Are you using io barriers?

[PATCH] blk: fix gendisk->in_flight accounting during barrier sequence

While executing barrrier sequence, the bar_rq which carries actual
write was accounted as normal IO on completion, while it wasn't on
queueing.  This caused gendisk->in_flight to be decremented by 1 after
each barrier thus messed up statistics.

This patch makes bar_rq not accounted as normal IO.  As the containing
barrier request as a whole is accounted, part of it shouldn't be.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jens Axboe <axboe@suse.de>

diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index eac48be..7eb36c5 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -3452,7 +3452,12 @@ void end_that_request_last(struct reques
 	if (unlikely(laptop_mode) && blk_fs_request(req))
 		laptop_io_completion();
 
-	if (disk && blk_fs_request(req)) {
+	/*
+	 * Account IO completion.  bar_rq isn't accounted as a normal
+	 * IO on queueing nor completion.  Accounting the containing
+	 * request is enough.
+	 */
+	if (disk && blk_fs_request(req) && req != &req->q->bar_rq) {
 		unsigned long duration = jiffies - req->start_time;
 		const int rw = rq_data_dir(req);
 

-- 
Jens Axboe


  reply	other threads:[~2006-05-23  9:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-23  8:52 wrong in_flight diskstat in 2.6.16.1 Martin Devera
2006-05-23  9:23 ` Jens Axboe [this message]
2006-05-23  9:30   ` Martin Devera
2006-05-23  9:47     ` Jens Axboe

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=20060523092324.GO26261@suse.de \
    --to=axboe@suse.de \
    --cc=devik@cdi.cz \
    --cc=linux-kernel@vger.kernel.org \
    /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