* minor doc correction: Documentation/iostats.txt: bit-size reference @ 2011-03-18 21:41 Linda Walsh 2011-03-18 22:08 ` Randy Dunlap 2011-03-22 22:10 ` [PATCH] Documentation/iostats.txt: bit-size reference etc Randy Dunlap 0 siblings, 2 replies; 5+ messages in thread From: Linda Walsh @ 2011-03-18 21:41 UTC (permalink / raw) To: LKML Documentation/iostats.txt describes fields in /proc/diskstats as 32-bit unsigned values that can wrap. On a 64-bit system, it appears they are 64-bit unsigned values. Should 'iostats.txt' describe fields as "unsigned, native-word-sized values" or is my 64-bit system not behaving according to "spec"? ;-) Linda ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: minor doc correction: Documentation/iostats.txt: bit-size reference 2011-03-18 21:41 minor doc correction: Documentation/iostats.txt: bit-size reference Linda Walsh @ 2011-03-18 22:08 ` Randy Dunlap 2011-03-22 22:10 ` [PATCH] Documentation/iostats.txt: bit-size reference etc Randy Dunlap 1 sibling, 0 replies; 5+ messages in thread From: Randy Dunlap @ 2011-03-18 22:08 UTC (permalink / raw) To: Linda Walsh; +Cc: LKML, axboe On Fri, 18 Mar 2011 14:41:28 -0700 Linda Walsh wrote: > > > Documentation/iostats.txt describes fields in /proc/diskstats as > 32-bit unsigned values that can wrap. > > On a 64-bit system, it appears they are 64-bit unsigned values. > > Should 'iostats.txt' describe fields as "unsigned, native-word-sized > values" or is my 64-bit system not behaving according to "spec"? ;-) They are "unsigned long", so yes, that is basically your native-word-sized values. That text file was written in 2003 or earlier, so things have changed a bit (or several bits) since then. thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] Documentation/iostats.txt: bit-size reference etc. 2011-03-18 21:41 minor doc correction: Documentation/iostats.txt: bit-size reference Linda Walsh 2011-03-18 22:08 ` Randy Dunlap @ 2011-03-22 22:10 ` Randy Dunlap 2011-03-23 7:29 ` Jens Axboe 1 sibling, 1 reply; 5+ messages in thread From: Randy Dunlap @ 2011-03-22 22:10 UTC (permalink / raw) To: Linda Walsh, axboe; +Cc: LKML From: Randy Dunlap <randy.dunlap@oracle.com> - correction that disk stats values are native-word-sized 32-bit or 64-bit values, not always 32-bi values - drop "Last modified" entry; use git for that - fix a few typos - change "cpu" to "CPU" Reported-by: Linda Walsh <lkml@tlinx.org> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- Documentation/iostats.txt | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) --- linux-2.6.38-git11.orig/Documentation/iostats.txt +++ linux-2.6.38-git11/Documentation/iostats.txt @@ -1,8 +1,6 @@ I/O statistics fields --------------- -Last modified Sep 30, 2003 - Since 2.4.20 (and some versions before, with patches), and 2.5.45, more extensive disk statistics have been introduced to help measure disk activity. Tools such as sar and iostat typically interpret these and do @@ -46,11 +44,12 @@ the above example, the first field of st By contrast, in 2.6 if you look at /sys/block/hda/stat, you'll find just the eleven fields, beginning with 446216. If you look at /proc/diskstats, the eleven fields will be preceded by the major and -minor device numbers, and device name. Each of these formats provide +minor device numbers, and device name. Each of these formats provides eleven fields of statistics, each meaning exactly the same things. All fields except field 9 are cumulative since boot. Field 9 should -go to zero as I/Os complete; all others only increase. Yes, these are -32 bit unsigned numbers, and on a very busy or long-lived system they +go to zero as I/Os complete; all others only increase (unless they +overflow and wrap). Yes, these are (32-bit or 64-bit) unsigned long +(native word size) numbers, and on a very busy or long-lived system they may wrap. Applications should be prepared to deal with that; unless your observations are measured in large numbers of minutes or hours, they should not wrap twice before you notice them. @@ -96,11 +95,11 @@ introduced when changes collide, so (for read I/Os issued per partition should equal those made to the disks ... but due to the lack of locking it may only be very close. -In 2.6, there are counters for each cpu, which made the lack of locking -almost a non-issue. When the statistics are read, the per-cpu counters -are summed (possibly overflowing the unsigned 32-bit variable they are +In 2.6, there are counters for each CPU, which make the lack of locking +almost a non-issue. When the statistics are read, the per-CPU counters +are summed (possibly overflowing the unsigned long variable they are summed to) and the result given to the user. There is no convenient -user interface for accessing the per-cpu counters themselves. +user interface for accessing the per-CPU counters themselves. Disks vs Partitions ------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Documentation/iostats.txt: bit-size reference etc. 2011-03-22 22:10 ` [PATCH] Documentation/iostats.txt: bit-size reference etc Randy Dunlap @ 2011-03-23 7:29 ` Jens Axboe 2011-03-23 15:44 ` [PATCH resend] " Randy Dunlap 0 siblings, 1 reply; 5+ messages in thread From: Jens Axboe @ 2011-03-23 7:29 UTC (permalink / raw) To: Randy Dunlap; +Cc: Linda Walsh, LKML On 2011-03-22 23:10, Randy Dunlap wrote: > From: Randy Dunlap <randy.dunlap@oracle.com> > > - correction that disk stats values are native-word-sized > 32-bit or 64-bit values, not always 32-bi values > - drop "Last modified" entry; use git for that > - fix a few typos > - change "cpu" to "CPU" Randy, this one doesn't apply at all: patching file Documentation/iostats.txt Hunk #1 FAILED at 1. Hunk #2 FAILED at 46. Hunk #3 FAILED at 96. -- Jens Axboe ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH resend] Documentation/iostats.txt: bit-size reference etc. 2011-03-23 7:29 ` Jens Axboe @ 2011-03-23 15:44 ` Randy Dunlap 0 siblings, 0 replies; 5+ messages in thread From: Randy Dunlap @ 2011-03-23 15:44 UTC (permalink / raw) To: Jens Axboe; +Cc: Linda Walsh, LKML From: Randy Dunlap <randy.dunlap@oracle.com> - correction that disk stats values are native-word-sized 32-bit or 64-bit values, not always 32-bi values - drop "Last modified" entry; use git for that - fix a few typos - change "cpu" to "CPU" Reported-by: Linda Walsh <lkml@tlinx.org> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- [fix the alpine usage attempt that failed] Documentation/iostats.txt | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) --- linux-2.6.38-git11.orig/Documentation/iostats.txt +++ linux-2.6.38-git11/Documentation/iostats.txt @@ -1,8 +1,6 @@ I/O statistics fields --------------- -Last modified Sep 30, 2003 - Since 2.4.20 (and some versions before, with patches), and 2.5.45, more extensive disk statistics have been introduced to help measure disk activity. Tools such as sar and iostat typically interpret these and do @@ -46,11 +44,12 @@ the above example, the first field of st By contrast, in 2.6 if you look at /sys/block/hda/stat, you'll find just the eleven fields, beginning with 446216. If you look at /proc/diskstats, the eleven fields will be preceded by the major and -minor device numbers, and device name. Each of these formats provide +minor device numbers, and device name. Each of these formats provides eleven fields of statistics, each meaning exactly the same things. All fields except field 9 are cumulative since boot. Field 9 should -go to zero as I/Os complete; all others only increase. Yes, these are -32 bit unsigned numbers, and on a very busy or long-lived system they +go to zero as I/Os complete; all others only increase (unless they +overflow and wrap). Yes, these are (32-bit or 64-bit) unsigned long +(native word size) numbers, and on a very busy or long-lived system they may wrap. Applications should be prepared to deal with that; unless your observations are measured in large numbers of minutes or hours, they should not wrap twice before you notice them. @@ -96,11 +95,11 @@ introduced when changes collide, so (for read I/Os issued per partition should equal those made to the disks ... but due to the lack of locking it may only be very close. -In 2.6, there are counters for each cpu, which made the lack of locking -almost a non-issue. When the statistics are read, the per-cpu counters -are summed (possibly overflowing the unsigned 32-bit variable they are +In 2.6, there are counters for each CPU, which make the lack of locking +almost a non-issue. When the statistics are read, the per-CPU counters +are summed (possibly overflowing the unsigned long variable they are summed to) and the result given to the user. There is no convenient -user interface for accessing the per-cpu counters themselves. +user interface for accessing the per-CPU counters themselves. Disks vs Partitions ------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-03-23 15:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-18 21:41 minor doc correction: Documentation/iostats.txt: bit-size reference Linda Walsh 2011-03-18 22:08 ` Randy Dunlap 2011-03-22 22:10 ` [PATCH] Documentation/iostats.txt: bit-size reference etc Randy Dunlap 2011-03-23 7:29 ` Jens Axboe 2011-03-23 15:44 ` [PATCH resend] " Randy Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox