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