On Fri, Jul 08 2005, Andrew Morton wrote: > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > Some more investigation - it appears to be broken read-ahead, actually. > > 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 { > > Interesting. We should be turning that back off in handle_ra_miss() as > 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 -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/