RE: Unresponiveness of 2.4.16

[Torrey Hoffman]

I've running 2.4.16 with this VM patch combined with your
2.4.15-pre7-low-latency patch from www.zip.com.au.  (it applied with a
little fuzz, no rejects). Is this a combination that you would feel
comfortable with?

So far it hasn't blown up on me, and in fact seems very quick and
responsive.  

Unless I hear a "No, don't do that!", I'm going to push this kernel into
testing for our video applications...

Thanks!

Torrey Hoffman
[e-mail]

Andrew Morton wrote:
[...] 
> Description:
> 
> - Account for locked as well as dirty buffers when deciding
>   to throttle writers.
> 
> - Tweak VM to make it work the inactive list harder, before starting
>   to evict pages or swap.
> 
> - Change the elevator so that once a request's latency has
>   expired, we can still perform merges in front of that
>   request.  But we no longer will insert new requests in
>   front of that request.  
> 
> - Modify elevator so that new read requests do not have
>   more than N write requests placed in front of them, where
>   N is tunable per-device with `elvtune -b'.
> 
>   Theoretically, the last change needs significant alterations
>   to the readhead code.  But a rewrite of readhead made negligible
>   difference (I wasn't able to trigger the failure scenario).
>   Still crunching on this.