Re: [PATCH/RFC] Simplified Readahead

[Joel Schopp]

> The key design point of the new design is to make the readahead code 
> aware of the size of the I/O request.  This change eliminates the need 
> for treating large random I/O as sequential and all of the averaging 
> code that exists just to support this.  In addition to this change, the 
> new design ramps up quicker, and shuts off faster.  This, combined with 
> the request size awareness eliminates the so called "slow read path" 
> that we try so hard to avoid in the current code.  For complete details 
> on the design of the new readahead logic, please refer to 
> http://www-124.ibm.com/developerworks/opensource/linuxperf/readahead/read-ahead-design.pdf 

I do love the design.  Certainly an improvement over what we currently 
have in all ways I can think of.

> There are a few exception cases which still concern me.
> 1. pages already in cache
> 2. I/O queue congestion.
> 3. page stealing

Correct me if I am wrong on this.  But if there was simultaneous 
multithreaded reading on a single file would it look non sequential and 
not trigger readahead?  For instance if on a 4 processor system 4 
threads were each reading 1/4 of the single file sequentially.  Would 
this be exception case number 4?

I don't know if this is a common scenario, just a plausible one.  I also 
don't know a good way to deal with it.  Current code is just as 
susceptible to it in any case.  Nothing to hold up putting this in, just 
curious if somebody knows how we might deal with it properly.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/