Re: [git patches] IDE update

[Steven Pratt <slpratt@austin.ibm.com>]

Jens Axboe wrote:

> 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
>  

I don't see how this is broken.  The INCACHE flag should be cleared on 
the first miss.  We will start up I/O slightly slower in this case since 
it is not 1st IO, but within about 5 or 6 reads we should be back to 
normal max_readahead behavior.  This is what I see on my old laptop.


patches:/home/slpratt # ./readdisk /dev/hda
Disk Throughput: 16 MiB/sec
patches:/home/slpratt # ./readdisk /dev/hda 1
Mem Throughput: 145 MiB/sec
Mem Throughput: 153 MiB/sec
Disk Throughput: 16 MiB/sec


Can you post iostat -x output from your runs.  Are we doing the right 
sized IO?

Steve



-
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/