Elevator algorithm parameters

[LA Walsh <law@sgi.com>]

I have a few comments/questions on the elv. alg. as it is now.  Some
of them may be based on a flawed understanding, but please be patient
anyway :-).

1) read-ahead is given the same 'latency' [max-wait priority] as 'read'
   I can see r-a as being less important than 'read' -- 'read' means
   some app is blocked waiting for input *now*.  'ra' -- means the
   kernel is being clever in hopes it is predicting a usage pattern where
   reading ahead will be useful.  I'd be tempted to give read-ahead
   a higher acceptable latency than reads and possibly higher than
   writes.  By definition, 'ra' i/o is i/o that no one currently has
   requested be done.
   a) the code may be there, but if a read request comes in for a
      sector marked for ra, then the latency should be set to 
      min(r-latency,remaining ra latency)

2) I seem to notice a performance boost for my laptop setting the
   read latency down to 1/8th of the write (2048/16384) instead of
   the current 1:2 ratio.  

   I am running my machine as a nfs server as well as doing local tasks
   and compiles.  I got better overall performance because nfs requests
   got serviced more quickly to feed a data-hungry dual-processor
   "compiler-server".  Also, my interactive processes which need
   lots of random reads perform better because they got 'fed' faster
   while some background data transfers (read and writes) of large
   streams of data were going on.

3) It seems that the balance of optimal latency figures would vary
   based on how many cpu-processes are blocked on data-reads, how many
   cpu's are reading from the same disk, the disk speed, the cpu speed
   and available memory for buffering.  Maybe there is a neat wiz-bang
   self-adjusting algorithm that can adapt dynamically to different
   loads (like say detects -- hmmm, we have 100 non mergable read 
   requests plugged, should I wait for more?...well only 1 active write
   request is running....maybe I should lower the read latency...etc).
   However, in the interim, it seems having the values at least be
   tunable via /proc (rather than the current ioctl) would be useful --
   just able to echo some values into there @ runtime.  I couldn't
   seem to find such a beast in /proc.

Comments/cares?

If you ask for code from me, it'll be a while -- My read and write 
-- 
L A Walsh                        | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338