lkml.org 
[lkml]   [2000]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: elevator-starvation-4 (2.2.14 && 2.3.42)

Rik,

The simple way around this is to process the IO request list
**backwards** when you parse the elements and do the disk IO. This is
what we do in NetWare mirroring (Novell figured this out after about 7
years of putzing around with different elevator routines), and gets
around the problem of folks constantly adding new entries that starve
those lower on the list. The implementation requires an 'A' and 'B'
list of IO requests. What we do is just take the entire list at the
head, zero the list head and tail, and process the list from a local
"head" in the async IO process (which allows folks to keep adding new
requests to the queue).

Hope this helps.

Jeff

Rik van Riel wrote:
>
> On Thu, 10 Feb 2000, Bruce Thompson wrote:
>
> > Lemme sort of restate the question I have then: Is the goal to
> > ensure that the elevator algorithm does not result in indefinite
> > postponement? If so then I assert that a correct implementation of
> > the elevator algorithm is guaranteed to prevent indefinite
> > postponement. Or, is the goal to ensure that any given request is
> > not delayed for an unreasonable length of time
>
> The latter. We want to maximise request latency to something
> relatively small because we don't want one flood of requests
> to stall something else in the system.
>
> > I would argue then that a fruitful line of attack would be to
> > ensure that you can service N + 1 requests in the time that N
> > requests are generated
>
> This is very much impossible because hard disks are a *LOT*
> slower than main memory or the cpu. There is simply no way
> that a hard disk can outrun a modern cpu...
>
> Rik
> --
> The Internet is not a network of computers. It is a network
> of people. That is its real strength.
>
> -
> 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/

-
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/

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