Re: [git patches] IDE update

[Jens Axboe <axboe@suse.de>]

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