Messages in this thread |  | | Subject | Re: [Ext2-devel] disk throughput | From | Jeremy Fitzhardinge <> | Date | 09 Nov 2001 00:49:17 -0800 |
| |
On Thu, 2001-11-08 at 22:08, Andrew Morton wrote: > How do you avoid aftifacts from Linux caching with this test?
Randomly seeking around a 40G disk isn't going to give the caching much to work with (that was on a 256Mbyte machine). Also, I tried it with raw devices, but it made no difference to the measurements.
> > I found the random seeking was the only way I could get reasonable > > numbers out of the drive; any of the ordered patterns of the form "OK, > > lets measure N block seeks" seemed to be predicted by the drive and gave > > unreasonably fast results. > > > > But we *want* unreasonably fast results! We need to understand > this device-level prediction, then decide if it's sufficiently > widespread for us to go and exploit the hell out of it. > > Have you any ideas as to what's happening?
Not really. I wanted results which at least confirm the simple model of how the disk works. When I did deterministic seeks, it was something like:
for(n = 0; n < disksize/2; n += about_a_cylinder) { seek(n); read(); seek(disksize-n); read(); }
I suspect that the drive was partitioning its cache and using lots of readahead to satisfy the reads at either end of the seek. I was trying to work around that by making the n increment large enough, but it didn't seem to work. Maybe the drive was being extra special clever, or maybe I miscalculated the cylinder size. Or maybe I just happened to be hitting a rotational sweet-spot.
For this kind of test, it would be interesting to know what differences there are between read and write. In principle the drive could start writing a track anywhere it wants so long as it has enough to write the whole thing. That would automatically make it get the track-track skew right...
J
- 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/
|  |