Re: [git patches] IDE update

[Jens Axboe <axboe@suse.de>]

On Fri, Jul 08 2005, Jens Axboe wrote:
> On Tue, Jul 05 2005, Linus Torvalds wrote:
> > So my gut feel is that the reason hdparm and dd from the raw partition 
> > gives different performance is not so much the driver, but probably that 
> > we've tweaked read-ahead for file access or something like that. Maybe 
> > the maximum fs-level read-ahead changed?
> 
> I don't think this is the case. I butchered a test system here and
> successfully got it running a P2 at 375MHz (don't ask, messing with
> multipliers and FSB with slot-1 cpu's has been a while) and 2.6 was
> still faster.
> 
> But! I used hdparm -t solely, 2.6 was always ~5% faster than 2.4. But
> using -Tt slowed down the hd speed by about 30%. So it looks like some
> scheduler interaction, perhaps the memory timing loops gets it marked as
> batch or something?

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 {

-- 
Jens Axboe