kstat should be a lighter-weight per-cpu thing. But the current
disk accounting in there would make it 12 kilobytes per CPU.
My vote: remove the disk accounting from kernel_stat and use this.
I have a patch from another contributor that takes disk stats out of
kstat and puts them into their own global structure. I'll give that
some attention.
> What follows works, but needs refinements. Comments welcome.
What are those refinements?
A couple I mentioned in my message: double collection of stats, and an
ugly hd_struct added to gendisk. In addition, we should remove the
restriction on which and how many disks are reported on.
Lastly, a bit of a philosophical question. /proc/stat and (with this
patch) /proc/diskstats provide some of the same information. Should
a) all of it appear in /proc/stat?
b) all of it appear in /proc/diskstats?
c) keep the current (limited) info in /proc/stat (for backward
compatibility) and introduce the expanded info in
/proc/diskstats?
My preference is b, but I'm open to other opinions.
What userspace tools are available for interpreting this
information?
None that I'm aware of, although /proc/diskstats is formatted in a
program-friendly way. Sample output (warning: wide):
major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq
f7d1e414 8 0 0 sda 1657 1403 46534 17391 3633 3974 61480 179110 0 34876 196501
f7c18000 8 1 2562367 sda1 1609 0 41522 0 5285 0 42280 0 0 0 0
f7c1810c 8 2 1 sda2 0 0 0 0 0 0 0 0 0 0 0
f7c18324 8 4 56196 sda4 96 0 768 0 0 0 0 0 0 0 0
f7c18430 8 5 1052226 sda5 16 0 128 0 0 0 0 0 0 0 0
f7c1853c 8 6 1052226 sda6 379 0 2802 0 2380 0 19032 0 0 0 0
f7c18648 8 7 13044748 sda7 946 0 1202 0 18 0 168 0 0 0 0
Just realized as I printed this that the first field is leftover
debugging, and should be removed!
Rick
-
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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:28 EST