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
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
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
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
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
On Tue, Sep 19, 2000 at 08:30:05PM +0200, Peter Osterlund wrote:
> It is however possible to decide in O(1) time if the correct insertion
> point is at the end of the queue. We have to keep track of the point,
Right.
> [..] How long
> can the request queue be? Does it have a fixed upper size,
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
>
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
>
Rik van Riel <[EMAIL PROTECTED]> writes:
> 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)
>
> AND
>
> 2) the block number is smaller than head (or head->next
>
On Tue, Sep 19, 2000 at 07:17:42AM -0300, 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)
If you read the code you'll see that in his previous
On Tue, Sep 19, 2000 at 04:50:26AM -0300, Rik van Riel wrote:
> When the latency gets above 10 minutes, I'd call it starvation ;)
Me too, no argument about that.
> Not average latency no, but the starvation issue should be
> fixed...
2.2.18pre9aa1 delivers acceptable latency for me with the
On 18 Sep 2000, Peter Osterlund wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> writes:
>
> > > 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
On Mon, 18 Sep 2000, Andrea Arcangeli wrote:
> On Sun, Sep 17, 2000 at 05:38:17PM -0300, Rik van Riel wrote:
> > Yes, I run my system with elvtune -r 250 -w 500.
>
> Ok (sorry for asking, it was just to be sure).
>
> > But even with -r 5 -w 5, I saw starvation. This, and
>
> I'd call it "too
On Mon, 18 Sep 2000, Andrea Arcangeli wrote:
On Sun, Sep 17, 2000 at 05:38:17PM -0300, Rik van Riel wrote:
Yes, I run my system with elvtune -r 250 -w 500.
Ok (sorry for asking, it was just to be sure).
But even with -r 5 -w 5, I saw starvation. This, and
I'd call it "too high
On 18 Sep 2000, Peter Osterlund wrote:
Andrea Arcangeli [EMAIL PROTECTED] writes:
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
On Tue, Sep 19, 2000 at 07:17:42AM -0300, 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)
If you read the code you'll see that in his previous patch
Rik van Riel [EMAIL PROTECTED] writes:
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)
AND
2) the block number is smaller than head (or head-next
if the
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:
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
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> > 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
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
Andrea Arcangeli [EMAIL PROTECTED] writes:
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
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
: And with the default latency values ("infinite") with the test2
: elevator if you're using scsi as your device, the patch can't make
: runtime differences either.
The test2 elevator (assuming it is the same as the test8 version) in the
infinite
On Sun, Sep 17, 2000 at 04:05:55PM -0300, Rik van Riel wrote:
> to be addressed ASAP. I've witnessed this starvation happen
> a couple of times and it's a really big problem...
Did you enabled the latency control as I suggested you a few days ago?
Andrea
-
To unsubscribe from this list: send
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> On Sun, Sep 17, 2000 at 04:05:55PM -0300, Rik van Riel wrote:
> > to be addressed ASAP. I've witnessed this starvation happen
> > a couple of times and it's a really big problem...
>
> Did you enabled the latency control as I suggested you a few
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> If nobody does that before me I will try this "remeber last position of the
> head" idea in my blkdev tree (there are many other pending elevator fixes in
> it) as soon as I finished with 2.2.18pre9aa1 LFS nfsv3 and as soon as I finish
> the fix
On Sun, Sep 17, 2000 at 04:39:35PM -0300, Marcelo Tosatti wrote:
>
> On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
>
>
>
> > If nobody does that before me I will try this "remeber last position of the
> > head" idea in my blkdev tree (there are many other pending elevator fixes in
> > it) as
On Sun, Sep 17, 2000 at 05:38:17PM -0300, Rik van Riel wrote:
> Yes, I run my system with elvtune -r 250 -w 500.
Ok (sorry for asking, it was just to be sure).
> But even with -r 5 -w 5, I saw starvation. This, and
I'd call it "too high latency", not starvation. Well, strictly speaking it's
On Sun, 17 Sep 2000, Rik van Riel wrote:
> On 17 Sep 2000, Peter Osterlund wrote:
> > Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> >
> > > While the queue is plugged or with things like SCSI your logic
> > > change won't work because in such case if your request is lower the
> > > lowest in
On Sun, Sep 17, 2000 at 10:53:17PM +0200, Peter Osterlund wrote:
> The test2 elevator (assuming it is the same as the test8 version) in the
Yes it's the same in such respect.
> infinite latency case will always send the request with the lowest sector
> number to the drive. (The request queue
On 17 Sep 2000, Peter Osterlund wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> writes:
>
> > While the queue is plugged or with things like SCSI your logic
> > change won't work because in such case if your request is lower the
> > lowest in the queue, you can put it at the head of the queue and
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> The patch is buggy for non headactive devices like SCSI and also for
> IDE while the queue is plugged.
Thanks for looking at the patch. Yes, sorry, I misunderstood the linux
linked list implementation. This is easy to fix though. See new patch
at
On Sun, Sep 17, 2000 at 01:26:22AM +0200, Peter Osterlund wrote:
> Indeed, the elevator logic is somewhat flawed. There are two problems
> with the current code:
>
> 1. The test that decides if we have found a good spot to insert the
>current request doesn't handle the wraparound case
On Sun, Sep 17, 2000 at 01:26:22AM +0200, Peter Osterlund wrote:
Indeed, the elevator logic is somewhat flawed. There are two problems
with the current code:
1. The test that decides if we have found a good spot to insert the
current request doesn't handle the wraparound case correctly.
On Sun, Sep 17, 2000 at 05:38:17PM -0300, Rik van Riel wrote:
Yes, I run my system with elvtune -r 250 -w 500.
Ok (sorry for asking, it was just to be sure).
But even with -r 5 -w 5, I saw starvation. This, and
I'd call it "too high latency", not starvation. Well, strictly speaking it's
not
On Sun, Sep 17, 2000 at 04:39:35PM -0300, Marcelo Tosatti wrote:
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
snip
If nobody does that before me I will try this "remeber last position of the
head" idea in my blkdev tree (there are many other pending elevator fixes in
it) as soon as
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
snip
If nobody does that before me I will try this "remeber last position of the
head" idea in my blkdev tree (there are many other pending elevator fixes in
it) as soon as I finished with 2.2.18pre9aa1 LFS nfsv3 and as soon as I finish
the fix
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
: And with the default latency values ("infinite") with the test2
: elevator if you're using scsi as your device, the patch can't make
: runtime differences either.
The test2 elevator (assuming it is the same as the test8 version) in the
infinite
Ragnar Kjørstad <[EMAIL PROTECTED]> writes:
> If I understand the current code correctly, it works like this:
[ example deleted ]
> So we've ended up with a very silly queue
Indeed, the elevator logic is somewhat flawed. There are two problems
with the current code:
1. The test that
Ragnar Kjørstad [EMAIL PROTECTED] writes:
If I understand the current code correctly, it works like this:
[ example deleted ]
So we've ended up with a very silly queue
Indeed, the elevator logic is somewhat flawed. There are two problems
with the current code:
1. The test that decides if
41 matches
Mail list logo
