public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Seger <Mark.Seger@hp.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org, sebastien.godard@wanadoo.fr
Subject: Re: Patch for inconsistent recording of block device statistics
Date: Wed, 23 Mar 2005 09:40:35 -0500	[thread overview]
Message-ID: <42417FE3.2090506@hp.com> (raw)
In-Reply-To: <20050323091916.GO24105@suse.de>


>I don't like this patch, it adds 4 * sizeof(unsigned long) to struct
>request when it can be solved without adding anything. The idea is
>sound, though, the current way the stats are done isn't very
>interesting.
>  
>
Actually I wasn't all that excited about using the extra variable 
myself.  However, I wasn't entirely sure what was going on and this at 
least allowed me to test the concept without doing anything harmful. 

>How about accounting merges the way we currently do it, since that piece
>of the stats _is_ interesting at queueing time. And then account
>completion in __end_that_request_first(). Untested patch attached.
>  
>
I also agree with your suggestion about keeping the merged counts where 
they are and am copying the author of iostat to suggest the man page be 
updated to reflect the fact that merges are counts for requests queued 
rather than 'issued to the device' as it currently states.

re: your patch - I did try it on both an Operton and Xeon box.  It 
worked find on the Opeteron and reported 0 for all the sectors on the 
Xeon.  If nothing immediately jumps to your mind could it have been 
something I did wrong?  I'll try another build after I send this along, 
but I don't see how that will help as I did the first one from a brand 
new source kit.

The one thing that still jumps out at me about this patch is that the 
sectors are being counted in one routine and the number of I/Os in 
another.  If the best place to update the sector counts is indeed where 
you suggest doing it, is there any reason not to move the update code 
for all the disk stats from end_that_request_last() to that same place 
as well for consistency and for better assurances that they are updated 
as close to the same point in time as possible?

-mark


  reply	other threads:[~2005-03-23 14:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-22 21:50 Patch for inconsistent recording of block device statistics Mark Seger
2005-03-23  9:19 ` Jens Axboe
2005-03-23 14:40   ` Mark Seger [this message]
2005-03-23 15:51     ` Jens Axboe
2005-03-23 18:23       ` Mark Seger
2005-03-23 18:33         ` Jens Axboe
2005-03-24  2:27           ` Mark Goodwin
2005-03-24  6:50             ` Jens Axboe
2005-03-23 15:49 ` Process level I/O stats? Mark Seger
2005-03-23 15:54   ` 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=42417FE3.2090506@hp.com \
    --to=mark.seger@hp.com \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sebastien.godard@wanadoo.fr \
    /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