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