[lkml]   [2001]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectElevator algorithm parameters
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.


If you ask for code from me, it'll be a while -- My read and write
L A Walsh | Trust Technology, Core Linux, SGI | Voice: (650) 933-5338
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:29    [W:0.028 / U:28.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site