Re: [git patches] IDE update

Jens Axboe
2005-07-08T09:52:27Z

On Fri, Jul 08 2005, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> 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