On Tue, Sep 19 2000, Andrea Arcangeli wrote:
> > 7[3] 8[2] 9[1] 10[0] 3[3] 4[2] 5[1] 6[0] 1[3] 2[2]
> p
> With point `p' I mean the request after last barrier in the queue.
Ah, I suspected we were talking past each other.
> Then when we try to insert 99 i
On Tue, Sep 19, 2000 at 10:38:52PM +0200, Jens Axboe wrote:
> I haven't had a chance to really look at Peter's mods yet, but surely
> the current elevator can have many entries with 0 sequence. As an
> example, say the start sequence is 3 and we received request sector
> 10...1 in descending order
On Tue, Sep 19 2000, Andrea Arcangeli wrote:
> > I don't see any reason why there can't be multiple p points in the current
> > elevator.
>
> Without the proposed modification after the last barrier in the queue all the
> requests should be in order.
I haven't had a chance to really look at Pete
On Tue, Sep 19, 2000 at 09:41:17PM +0200, Jens Axboe wrote:
> I don't see any reason why there can't be multiple p points in the current
> elevator.
Without the proposed modification after the last barrier in the queue all the
requests should be in order.
Andrea
-
To unsubscribe from this list:
On Tue, Sep 19 2000, Andrea Arcangeli wrote:
> > But there may be several p points in the queue, how are you going
> > to keep track of all of them?
>
> With the current elevator there should be only 1 p point, but with the
I don't see any reason why there can't be multiple p points in the curre
On Tue, Sep 19, 2000 at 09:17:51PM +0200, Jens Axboe wrote:
> But there may be several p points in the queue, how are you going
> to keep track of all of them?
With the current elevator there should be only 1 p point, but with the
modification Peter suggested there can be more and we should track
On Tue, Sep 19 2000, Peter Osterlund wrote:
> > 2) the block number is smaller than head (or head->next
> >if the current request is unplugged)
>
> The second condition is not so simple in the case of latency control.
> Consider the following queue:
>
> sector: 100 200 300 400 10 20 30
> s
On Tue, Sep 19 2000, Rik van Riel wrote:
> This is a bug in Andrea's idea. The request should only
> be inserted at the end of the list if:
>
> 1) the block numbre is bigger than head->prev (which you
>already have)
Of course.
> 2) the block number is smaller than head (or head->next
>
8 matches
Mail list logo