lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: An elevator algorithm (patch)
On Sun, Sep 17, 2000 at 08:57:00PM +0200, Peter Osterlund wrote:
> The new patch will obey the latency requirement but still keep disk
> seeks to a minimum. This makes it possible to use much smaller latency

Yes I agree that's a much nicer behaviour with strict latency requirements
(that's what 2.2.1[67] is doing btw).

> values without losing streaming performance. (I used "elvtune -r 10000
> -w 200000" and didn't notice any slowdown in iozone and Bonnie. It is
> still faster than plain 2.4.0-test8)

You should be able to use 250/500 as well without slowdown.

> Yes, that would be even better, but IMHO the new patch is already
> better than what's currently in the kernel. (I don't think the

With scsi the new patch won't make any difference with the default latency
settings but I agree it's better for the other cases.

> The only disadvantage I can see is that the new patch doesn't handle
> consecutive insertions in O(1) time, but then again, the pre-latency

We can still do that by trivially fixing a bit your code. You should first
check if the new inserted request is over the last in the current queue before
entering the tmp1/tmp2 logic. If the new request is higher than read_head->prev
then you should insert at the tail of the queue in O(1). Please re-do the
patch doing this O(1) optimization for the common case then I'll recommend it
for integration (probably I can integrate it into my tree with lots of other
fixes from me and Jens and then I can upload a jumbo patch to test). I can
also integrate the suggestion from Stephen of accouting a "pass" due a merged
request as 1 and a "pass" due a separate scsi command as 2. Such heuristic
makes perfect sense to me too.

> + if (entry == real_head) {
> + /*
> + * Since we don't know were the disk head is
> + * currently located, we can not really know
> + * if the request should be inserted here. The
> + * best bet is probably not to insert the
> + * request here, because otherwise the
> + * elevator would be unfair to sectors at the
> + * end of the disk.
> + */

Agreed. Then once we'll add some more memory about the last position of the head
to the request_queue_t we'll be able to do even better choice.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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