Messages in this thread | | | Date | Thu, 3 May 2001 07:59:53 +1000 (EST) | From | Shaun <> | Subject | Re: Disk Performance Measurements |
| |
> > In regards to diskr/wblk, drive_stat_acct() increments the number of > > sectors/blocks read based n the values in the request being processed by > > add_request(). But add_request() is only called for requests that can't be > > merged with requests currently on the queue. Thus the counters can't be > > updated for sectors that are read by being added to aqueued > > request. Unless I'm mistaken this makes the diskr/wblk mostly useless. > > Look again, drive_stat_acct is also called for list merges (just with 0 > set for new i/o of course).
Ok, this problem must has been fixed in later versions. In my 2.2.16 kernel:
[shaunc@ufs block]$ grep -irn "drive_stat_acct" ll_rw_blk.c 307:static inline void drive_stat_acct(int cmd, unsigned long nr_sectors, 318: printk(KERN_ERR "drive_stat_acct: cmd not R/W?\n"); 676: * which is important for drive_stat_acct() above. */ 715: drive_stat_acct(req->cmd, req->nr_sectors, disk_index); [shaunc@ufs block]$ grep -irn "dk_drive_rblk" ll_rw_blk.c 313: kstat.dk_drive_rblk[disk_index] += nr_sectors;
> > record the _kilobytes_ read or written to the disks. His code adds > > drive_pg_stat_acct(). This routine increments disk_pgin/out once for each > > call to make_request(). Presumably he has assumed every call to > > make_request will always be for 2 sectors/1 Kilobytes worth of > > data. However I added printk() statements to try to verify this and found > > that the request to the block device need not be 1024 bytes, I frequently > > saw 4096 requests. In fact, the "correct_size" for the block device > > appeared to be changeable from partition to partition on the same > > disk. This "correct_size" appears to be related to the block size for the > > filesystem on the partition/disk? Following from the above logic it would > > appear that the pgin/pgout statistics are also useless since you don't > > know how large the requests were? > > The size of requests will typically vary with the block size set by > ext2. So if you have 1kB block size on your fs, that partition will > receive 1kB buffers. Similar for 4kB. The stats collected in the kernel > are sector based, units of 512 bytes. The proc printed value should be > in kB however for pgpin/out and 512b sectors for rio/rblk wio/wblk.
Again, this isn't the case in the 2.2.16 kernel I'm working with. Each call to make_request() causes pgin/pgout to be incremented, since these requests can be of different sizes (even for the same disk) I can't see how a kb value can be deduced.
Just as a question though, a disk/partition doesn't need to have a filesystem on it, so why is the "correct_size" for a buffer request on the block device defined based on a filesystem block system?
Thanks, Shaun
- 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/
| |