On Tue, 8 Feb 2000, Stephen C. Tweedie wrote:
>Hi,
>
>On Sat, 5 Feb 2000 23:37:44 +0100 (CET), Andrea Arcangeli
><andrea@suse.de> said:
>
>> A 2.3.42 version of my elevator latency stuff is here:
>> ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.3/2.3.42/elevator-starvation-3.gz
Very sorry WARNING: the above patch had a silly bug! A new (improved) one
is just ready though. I'll upload and announce soon.
The 2.2.x versions (-1 and -2 revisions) are unaffected by the bug thus
people using elevator-starvation-[12] against 2.2.14 can continue to use
them without any worry.
I'll release elevator-starvation-4.gz for both 2.2.14 and 2.3.42 the same
time though, since the new things I did in the 2.3.42 upcoming version are
good to have also in 2.2.14 (but for 2.2.x the update is only
a performance issues and none upgrade is necessary).
>Last time I looked at this problem, the hard part was to find a way of
>doing this which avoided scanning the whole queue looking for due
>requests. It looks like the only way you can do that easily is with a
>complex data structure such as avl-trees for the request list.
Yes the complexity and changes to the rest of the queue is definitely ugly
:( but breking scsi and all other blockdevices may be even uglier... So
for now I hurt CPU usage that nevertheless is still zero in the profiling
during heavy I/O load. After all the result of the algorithm would be the
same, only complexity changes.
>However, there was a mechanism which would allow you to deal with
>starvation by scanning the request queue, but without having to modify
>the whole queue when new requests are inserted.
>
>The elevator_starve_rest_of_queue() function can be avoided if you use
>sequence numbers instead, and give each request an IO sequence number at
>which point that request becomes "due". You still need to scan the
I can't do that for 2.2.x :(.
>whole queue to detect requests whose due dates have expired in order to
>avoid starvation, but you don't ever need to write to requests once they
>have been created, and that should make for much less CPU time consumed
>(especially on SMP).
_Completly_ agreed. I just had this in mind since I am been very happy to
notice the cool work that is been done on the ll_rw_block layer where now
the request_queue_t is available in the high layer. I'll try do that in
the -5 revision (the -4 revision is just ready and I just tested it for
both 2.2.x and 2.3.x and in the 2.2.x case I can't do better than that).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:12 EST