Subject: Re: disk statistics issue in 2.6.27
From: Miquel van Smoorenburg <mikevs@xs4all.net>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org, mikevs@xs4all.net
In-Reply-To: <20081031124743.GH31673@kernel.dk>
References: <20081019113102.GA18440@xs4all.net>
	 <20081020171248.GE19428@kernel.dk>
	 <1224686272.25437.14.camel@n2o.xs4all.nl>
	 <20081022171712.GO22217@kernel.dk>
	 <1224777902.26805.17.camel@n2o.xs4all.nl>
	 <20081031124743.GH31673@kernel.dk>
Content-Type: text/plain
Date: Mon, 03 Nov 2008 22:39:12 +0100
Message-Id: <1225748352.15785.5.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1754
Lines: 48

On Fri, 2008-10-31 at 13:47 +0100, Jens Axboe wrote:
> On Thu, Oct 23 2008, Miquel van Smoorenburg wrote:
>
> > I added some debug statements to block/blk-core.c, and it appears that
> > blk_end_io() is always called with nr_bytes == 16320 Kbytes (16711680).
> > 
> > Ofcourse I should have noticed earlier that iostat -x 2 always prints
> > 32640 as "average request size" (in sectors).
> 
> You didn't happen to log a backtrace from that, did you? That's a weird
> nr_bytes, it's 0xff0000.
> 
> I'm assuming this then fixes it, just wondering what the heck is going
> on here.
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 33c8d4b..a372618 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1712,11 +1710,12 @@ static int __end_that_request_first(struct request *req, int error,
>  	if (blk_fs_request(req) && req->rq_disk) {
>  		const int rw = rq_data_dir(req);
>  		struct hd_struct *part;
> -		int cpu;
> +		int cpu, sectors;
>  
> +		sectors = min_t(int, nr_bytes >> 9, req->hard_nr_sectors);
>  		cpu = part_stat_lock();
>  		part = disk_map_sector_rcu(req->rq_disk, req->sector);
> -		part_stat_add(cpu, part, sectors[rw], nr_bytes >> 9);
> +		part_stat_add(cpu, part, sectors[rw], sectors);
>  		part_stat_unlock();
>  	}

I didn't try the above patch yet (it might work), but I did find the
cause. I bisected the problem and it was caused by commit
427e59f09fdba387547106de7bab980b7fff77be , something in the scsi layer.
More on linux-scsi (I'll Cc you)

Thanks

Mike.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/