Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Jens Axboe
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

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Andrea Arcangeli
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

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Jens Axboe
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

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Andrea Arcangeli
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:

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Jens Axboe
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

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Andrea Arcangeli
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

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Jens Axboe
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 >

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Jens Axboe
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 >

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Andrea Arcangeli
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.

Re: (reiserfs) Re: An elevator algorithm (patch)

2000-09-19 Thread Jens Axboe
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 it