Ragnar Kjørstad wrote:
>
> On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote:
> > I think Xuan's algorithm is good, so I want to add to it.:-)
> >
> > Ragnar, I don't understand your objection to it. It is always the
> > case that if you specify real
> > time constraints that are impos
On Fri, Sep 22, 2000 at 03:23:26PM -0700, Hans Reiser wrote:
> I think Xuan's algorithm is good, so I want to add to it.:-)
>
> Ragnar, I don't understand your objection to it. It is always the
> case that if you specify real
> time constraints that are impossible then they aren't met.
My ob
On Sat, Sep 16, 2000 at 06:31:46PM +0200, Xuan Baldauf wrote:
> I do not understand you terminology. There is not one queue, there are two
> queues.
Two queues?
What elevator code are you guys refering to when refering to "current"
code? I just read the code for linux-2.4.0-test8 - that is the
Hans Reiser wrote:
> I think Xuan's algorithm is good, so I want to add to it.:-)
>
> Ragnar, I don't understand your objection to it. It is always the case that if you
>specify real
> time constraints that are impossible then they aren't met.
>
> If you want to get fancy you could sort all e
I think Xuan's algorithm is good, so I want to add to it.:-)
Ragnar, I don't understand your objection to it. It is always the case that if you
specify real
time constraints that are impossible then they aren't met.
If you want to get fancy you could sort all expired time limit requests by b
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 11:09:47PM +0200, Peter Osterlund wrote:
> So that leaves two choices:
>
> 1. Perfect elevator (CSCAN) without the O(1) optimization. (My second
>patch.)
We can try with 1. first.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Jens Axboe <[EMAIL PROTECTED]> writes:
> > modification Peter suggested there can be more and we should track the one
> > more on the back of the queue. I don't think it's worthwhile.
>
> Agree, I don't think the added complexity would be worth it.
So that leaves two choices:
1. Perfect elevat
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 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, or
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
>
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 p
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 sam
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 you
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 hi
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 inserte
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
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 late
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 the
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 days
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 s
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, 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 wil
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 y
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 th
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 correct
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
"Ragnar Kjørstad" wrote:
> On Sat, Sep 16, 2000 at 01:17:53PM +0200, Xuan Baldauf wrote:
> > I'm not a kernel hacker (and therefore I'm not familiar with the kernel
> > terminology), and maybe this idea is already old, but here is an
> > algorithm for an elevator which tries to guarantee smooth
On Sat, Sep 16, 2000 at 01:17:53PM +0200, Xuan Baldauf wrote:
> I'm not a kernel hacker (and therefore I'm not familiar with the kernel
> terminology), and maybe this idea is already old, but here is an
> algorithm for an elevator which tries to guarantee smoothness and no
> stalling:
>
> Every r
Hello,
I'm not a kernel hacker (and therefore I'm not familiar with the kernel
terminology), and maybe this idea is already old, but here is an
algorithm for an elevator which tries to guarantee smoothness and no
stalling:
Every rw-request gets an expiry timeout (e.g. in jiffies) where it's
comp
38 matches
Mail list logo
