On Fri, Jul 08 2005, Andrew Morton wrote:
Jens Axboe <axboe@xxxxxxx> wrote:
Some more investigation - it appears to be broken read-ahead, actually.Interesting. We should be turning that back off in handle_ra_miss() as
hdparm does repeated read(), lseek() loops which causes the read-ahead
logic to mark the file as being in cache (since it reads the same chunk
every time). Killing the INCACHE check (attached) makes it work fine for
me, Grant can you test if it "fixes" it for you as well?
No ideas how to fix the read-ahead logic right now, I pondered some
depedency on sequential but I don't see how it can work correctly for
other cases. Perhaps handle_ra_miss() just isn't being called
appropriately everywhere?
--- mm/readahead.c~ 2005-07-08 11:16:14.000000000 +0200
+++ mm/readahead.c 2005-07-08 11:17:49.000000000 +0200
@@ -351,7 +351,9 @@
ra->cache_hit += nr_to_read;
if (ra->cache_hit >= VM_MAX_CACHE_HIT) {
ra_off(ra);
+#if 0
ra->flags |= RA_FLAG_INCACHE;
+#endif
return 0;
}
} else {
soon as hdparm seeks away. I'd be suspecting that we're not correctly
undoing the resutls of ra_off() within handle_ra_miss(), except you didn't
comment that bit out.
Or the readahead code is working as intended, and hdparm is doing something
really weird which trips it up.
hdparm should also be misbehaving when run against a regular file, but it
looks like hdparm would need some alterations to test that.
Just use the test app I posted, it shows the problem just fine. If I use
a regular file, behaviour is identical as expected (ie equally broken
:-).
bart:/data1 # ./read_disk ./test 1
Mem Throughput: 101 MiB/sec
Mem Throughput: 103 MiB/sec
Disk Throughput: 22 MiB/sec
bart:/data1 # ./read_disk ./test
Disk Throughput: 29 MiB/sec