OK. First of all, I have serious problems with collecting all these
stats to hd_struct.
I agree. They should be part of a disk statistics structure somewhere,
and that should probably be made part of this patch.
a) _all_ stats you collect by request will be for entire disk.
By the time when request had been created, we simply don't remember
which partition it used to be. Pretending that they are
per-partition only obfuscates the things. Stats by bio are
per-partition, but... see below
Yeah, I noticed :) The best we can do now, I think, is collect
per-partition information in generic_make_request() before the
partition remap. After that, the information is gone, and trying to
carry it along gets real ugly, especially when you remember that I/O
requests can get merged.
But it *is* still useful to know which partitions are getting hit up
with requests. If you've got some data that is continually getting
read/written to disk in a particular area, then (for instance) you
might want to make that data reside on a memdisk, if possible. Or
mirror it, if you're using a volume manager, to spread the I/O out over
multiple copies.
It might. There is a big rewrite of that area going on right
now. In particular, we are getting to the point when _all_
block devices are going to acquire gendisks - partitioned or not.
Next step after that will be sane refcounting for gendisks and once
that is done we are getting rid of get_gendisk() for good - pointer
will be cached in struct block_device while it's open _and_ it will
replace ->rq_dev in struct request.
In a development tree, everybody's got to adjust. I've no problem
keeping up the patches, or in consulting with the team making the
changes you described, to make these statistic changes stick and not
look like they were glued on at the last minute. The statistics are
valuable
a) at a gross level to sysadmins trying to balance their disk I/O
b) at a finer level by performance tuners, looking to maximize their
I/O rates
and they're worth the work.
Since 10/31 looms ever closer, I presume the changes you mentioned
will be rolling out in force in the next few weeks?
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