On Sat, 16 Sep 2000, Giuliano Pochini wrote:
> I wrote, then got air-brushed out of the thread?!
> > That's one approach; I prefer my "weighted scoring" approach. Supposing we
> > have three devices: a solid state disk (instant "seeks"), a hard drive and
> > a tape. The SSD will benefit from
> The current HUGE queue size is probably another reason for
> the very bad latencies we sometimes see...
Yes, but if the queue is short processes are likely to remain
blocked in D state for more time and the chances to merge rq
are smaller.
IMHO we should add a way to give priority to rqs from
> That's one approach; I prefer my "weighted scoring" approach. Supposing we
> have three devices: a solid state disk (instant "seeks"), a hard drive and
> a tape. The SSD will benefit from merges (fewer commands to process), but
> not hugely - set both the metrics at 1, so a 64Kb request is
[EMAIL PROTECTED] wrote:
> If we played some "zippy" music that would add to the "feel". Of
> course, we could actually use benchmarks instead.
Benchmarks, famed for their universal appeal :-)
> And, to me, if kernel compiles take longer, I don't care how fast it "feels".
A kernel compile _by
On Sat, Sep 16, 2000 at 02:15:16PM +0200, Jamie Lokier wrote:
> [EMAIL PROTECTED] wrote:
> > > Sure the global system is slower. But the "interactive feel" is faster.
> >
> > Let's pop up little buttons to make it "feel" faster.
>
> If little buttons pop up quickly when I click on them, then
[EMAIL PROTECTED] wrote:
> > Sure the global system is slower. But the "interactive feel" is faster.
>
> Let's pop up little buttons to make it "feel" faster.
If little buttons pop up quickly when I click on them, then yes that's
better interactive feel. Sometimes the disk is involved in
[EMAIL PROTECTED] wrote:
Sure the global system is slower. But the "interactive feel" is faster.
Let's pop up little buttons to make it "feel" faster.
If little buttons pop up quickly when I click on them, then yes that's
better interactive feel. Sometimes the disk is involved in this.
That's one approach; I prefer my "weighted scoring" approach. Supposing we
have three devices: a solid state disk (instant "seeks"), a hard drive and
a tape. The SSD will benefit from merges (fewer commands to process), but
not hugely - set both the metrics at 1, so a 64Kb request is just
On Sat, 16 Sep 2000, Giuliano Pochini wrote:
I wrote, then got air-brushed out of the thread?!
That's one approach; I prefer my "weighted scoring" approach. Supposing we
have three devices: a solid state disk (instant "seeks"), a hard drive and
a tape. The SSD will benefit from merges
[EMAIL PROTECTED] wrote:
If we played some "zippy" music that would add to the "feel". Of
course, we could actually use benchmarks instead.
Benchmarks, famed for their universal appeal :-)
And, to me, if kernel compiles take longer, I don't care how fast it "feels".
A kernel compile _by
On Sat, Sep 16, 2000 at 02:15:16PM +0200, Jamie Lokier wrote:
[EMAIL PROTECTED] wrote:
Sure the global system is slower. But the "interactive feel" is faster.
Let's pop up little buttons to make it "feel" faster.
If little buttons pop up quickly when I click on them, then yes that's
On Tue, Sep 12, 2000 at 04:30:32PM +0200, Jamie Lokier wrote:
> Sure the global system is slower. But the "interactive feel" is faster.
Let's pop up little buttons to make it "feel" faster.
--
-
Victor Yodaiken
Finite State Machine
On Fri, Sep 15, 2000 at 09:08:25PM -0400, Giuliano Pochini wrote:
> Which is tightly dependent on the way we insert new rqs.
Sure the implementation would differ in function of the way we order the
requests during inserction, but the conceptual algorithm of the latency control
could remain the
> >It's a good way to avoid stalls, but IMHO I thing the elevator should
>
> Here you're talking about the latency control logic.
Which is tightly dependent on the way we insert new rqs.
> >not work this way. The main problem is that it doesn't minimize head
> >movement. For example, when
It's a good way to avoid stalls, but IMHO I thing the elevator should
Here you're talking about the latency control logic.
Which is tightly dependent on the way we insert new rqs.
not work this way. The main problem is that it doesn't minimize head
movement. For example, when comes a
On Fri, Sep 15, 2000 at 09:08:25PM -0400, Giuliano Pochini wrote:
Which is tightly dependent on the way we insert new rqs.
Sure the implementation would differ in function of the way we order the
requests during inserction, but the conceptual algorithm of the latency control
could remain the
Ragnar Kjørstad wrote:
>
> On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
> > If I may ask a potentially stupid question, how can request latency be
> > anything but a factor of time? Latency is how /long/ you (or the computer)
> > /waits/ for something. That defines it as
On Wed, 13 Sep 2000, Rik van Riel wrote:
> On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> This (IMHO) is wrong. When the drive has trouble keeping up
> with requests in FCFS order, we should do some elevator sorting
> to keep throughput high enough to deal with the requests we get.
Reversing
On Wed, 13 Sep 2000, Rik van Riel wrote:
On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
This (IMHO) is wrong. When the drive has trouble keeping up
with requests in FCFS order, we should do some elevator sorting
to keep throughput high enough to deal with the requests we get.
Reversing that,
Ragnar Kjørstad wrote:
On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
If I may ask a potentially stupid question, how can request latency be
anything but a factor of time? Latency is how /long/ you (or the computer)
/waits/ for something. That defines it as a
On Wed, Sep 13, 2000 at 08:08:12PM -0300, Rik van Riel wrote:
> On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> > On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
> > > > Another potentially stupid question:
> > > > When the queue gets too long/old, new requests should be put in
> > >
On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
> > > Another potentially stupid question:
> > > When the queue gets too long/old, new requests should be put in
> > > a new queue to avoid starvation for the ones in the current
> > >
On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
> > Another potentially stupid question:
> > When the queue gets too long/old, new requests should be put in
> > a new queue to avoid starvation for the ones in the current
> > queue, right?
>
> Indeed. That would solve the problem...
On Wed, Sep 13, 2000 at 08:08:51PM -0400, Giuliano Pochini wrote:
> > And if so, in what unit do you want to measure
> > latency if it isn't time?
>
> I had a look at the new elevator. I hope I'm not wrong here... Requests
> are added to the queue scanning it starting from the tail. When the
>
On Wed, 13 Sep 2000, Ragnar Kjørstad wrote:
> On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
> > If I may ask a potentially stupid question, how can request latency be
> > anything but a factor of time? Latency is how /long/ you (or the computer)
> > /waits/ for something.
On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
> If I may ask a potentially stupid question, how can request latency be
> anything but a factor of time? Latency is how /long/ you (or the computer)
> /waits/ for something. That defines it as a function of time.
Latency is
On 12 Sep 2000, at 18:08, Ed Tomlinson wrote:
> Hi,
>
> I made the comment because I remember back when the discussion was current
> on linux kernel. I thought Jeff Merkey's, message was to the point. Para-
> phrasing from memory, it was something to the effect that novell had
> tried many
> > Going in function of time is obviously wrong. A blockdevice can
> > write 1 request every two seconds or 1 request every msecond.
> > You can't assume anything in function of time _unless_ you have
> > per harddisk timing informations into the kernel.
>
> Uhmmm, isn't the elevator about
You're welcome.
:-)
Jeff
Hans Reiser wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > One important point on remirroring I did not mention in my post. In
> > NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
> > artificial starvation while remirring is going on. This was another
> "Jeff V. Merkey" wrote:
> >
> > One important point on remirroring I did not mention in my post. In
> > NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
> > artificial starvation while remirring is going on. This was another
> > optimization we learned the hard way by trying
- Original Message -
From: "Rik van Riel" <[EMAIL PROTECTED]>
> On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> > On Tue, 12 Sep 2000, Rik van Riel wrote:
> >
> > >Uhmmm, isn't the elevator about request /latency/ ?
> >
> > Yes, but definitely not absolute "time" latency.
>
> So what do
On Wed, 13 Sep 2000, Andrea Arcangeli wrote:
> On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
>
> >The "large queue" goes against the whole point of this exercise - that
> >is that if there are many items in the "queue" being sorted then
> >unlucky requests can end up waiting a long time to get
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
> James Sutherland wrote:
> > In terms of latency, I'd suggest we aim to keep the device in use all the
> > time we have outstanding requests: every time the device is ready to
> > accept a request, we feed it the "next" one in the queue; until it is
"Jeff V. Merkey" wrote:
>
> One important point on remirroring I did not mention in my post. In
> NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
> artificial starvation while remirring is going on. This was another
> optimization we learned the hard way by trying numerous
On Wed, 13 Sep 2000, Martin Dalecki wrote:
>Andrea Arcangeli wrote:
>>
>> On Tue, 12 Sep 2000, Martin Dalecki wrote:
>>
>> >First of all: In the case of the mp3 player and such there is already a
>> >fine
>> >proper way to give it better chances on getting it's job done smooth -
>> >RT kernel
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
>The "large queue" goes against the whole point of this exercise - that
>is that if there are many items in the "queue" being sorted then
>unlucky requests can end up waiting a long time to get serviced.
Yep.
Andrea
-
To unsubscribe from this
On Wed, 13 Sep 2000, Alan Cox wrote:
>> Yes, but "how hard is it reasonable for the kernel to try" is based on
>> both items. A good first order approximation is number of requests.
>
>I must strongly disagree with that claim. A request could be 512 bytes or
>128K.
Current elevator account
On Wed, 13 Sep 2000, Stephen C. Tweedie wrote:
>You could use number-of-sectors, but that can't distinguish between
>random access and sequential access.
We actually use the number of `buffer headers` that enters the
ll_rw_block layer. (if all the fses have 4k blocksize it become the number
of
James Sutherland wrote:
> In terms of latency, I'd suggest we aim to keep the device in use all the
> time we have outstanding requests: every time the device is ready to
> accept a request, we feed it the "next" one in the queue; until it is free
> again, requests pile up in the queue, being
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
> Alan Cox wrote:
> > > Yes, but "how hard is it reasonable for the kernel to try" is based on
> > > both items. A good first order approximation is number of requests.
> >
> > I must strongly disagree with that claim. A request could be 512 bytes
Alan Cox wrote:
> > Yes, but "how hard is it reasonable for the kernel to try" is based on
> > both items. A good first order approximation is number of requests.
>
> I must strongly disagree with that claim. A request could be 512 bytes or
> 128K.
Yeah, as sct pointed out this gets thorny.
On Wed, 13 Sep 2000, Matthew Kirkwood wrote:
> [0] Insert obligatory "why oh why" on Linus' not
> taking SCT's sar/iostat patches.
Indeed. It's a shame because 2.4 is gaining a relatively complete
"Enterprise checklist". It's a further shame because it's a non-intrusive
patch.
Yes,
> Yes, but "how hard is it reasonable for the kernel to try" is based on
> both items. A good first order approximation is number of requests.
I must strongly disagree with that claim. A request could be 512 bytes or
128K.
> It's still a queue - the queue of things we're going to take on this
On Tue, 12 Sep 2000, Rik van Riel wrote:
[ outrageous cc: list trimmed ]
> > >We simply keep track of how old the oldest request
> > >in the queue is, and when that request is getting
> > >too old (say 1/2 second), we /stop/ all the others
> >
> > Going in function of time is obviously wrong.
Hi,
On Tue, Sep 12, 2000 at 04:08:54PM +0200, Andrea Arcangeli wrote:
>
> >Andrea - latency is time measured and perceived. Doing it time based seems to
> >make reasonable sense. I grant you might want to play with the weighting per
>
> When you have a device that writes a request every two
Yes, but "how hard is it reasonable for the kernel to try" is based on
both items. A good first order approximation is number of requests.
I must strongly disagree with that claim. A request could be 512 bytes or
128K.
It's still a queue - the queue of things we're going to take on this
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
Alan Cox wrote:
Yes, but "how hard is it reasonable for the kernel to try" is based on
both items. A good first order approximation is number of requests.
I must strongly disagree with that claim. A request could be 512 bytes or
128K.
James Sutherland wrote:
In terms of latency, I'd suggest we aim to keep the device in use all the
time we have outstanding requests: every time the device is ready to
accept a request, we feed it the "next" one in the queue; until it is free
again, requests pile up in the queue, being sorted,
On Wed, 13 Sep 2000, Stephen C. Tweedie wrote:
You could use number-of-sectors, but that can't distinguish between
random access and sequential access.
We actually use the number of `buffer headers` that enters the
ll_rw_block layer. (if all the fses have 4k blocksize it become the number
of
On Wed, 13 Sep 2000, Alan Cox wrote:
Yes, but "how hard is it reasonable for the kernel to try" is based on
both items. A good first order approximation is number of requests.
I must strongly disagree with that claim. A request could be 512 bytes or
128K.
Current elevator account the
On Wed, 13 Sep 2000, Martin Dalecki wrote:
Andrea Arcangeli wrote:
On Tue, 12 Sep 2000, Martin Dalecki wrote:
First of all: In the case of the mp3 player and such there is already a
fine
proper way to give it better chances on getting it's job done smooth -
RT kernel sceduler priorities
"Jeff V. Merkey" wrote:
One important point on remirroring I did not mention in my post. In
NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
artificial starvation while remirring is going on. This was another
optimization we learned the hard way by trying numerous
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
James Sutherland wrote:
In terms of latency, I'd suggest we aim to keep the device in use all the
time we have outstanding requests: every time the device is ready to
accept a request, we feed it the "next" one in the queue; until it is free
On Wed, 13 Sep 2000, Andrea Arcangeli wrote:
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
The "large queue" goes against the whole point of this exercise - that
is that if there are many items in the "queue" being sorted then
unlucky requests can end up waiting a long time to get
- Original Message -
From: "Rik van Riel" [EMAIL PROTECTED]
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
On Tue, 12 Sep 2000, Rik van Riel wrote:
Uhmmm, isn't the elevator about request /latency/ ?
Yes, but definitely not absolute "time" latency.
So what do you think about
"Jeff V. Merkey" wrote:
One important point on remirroring I did not mention in my post. In
NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
artificial starvation while remirring is going on. This was another
optimization we learned the hard way by trying numerous
You're welcome.
:-)
Jeff
Hans Reiser wrote:
"Jeff V. Merkey" wrote:
One important point on remirroring I did not mention in my post. In
NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
artificial starvation while remirring is going on. This was another
On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
If I may ask a potentially stupid question, how can request latency be
anything but a factor of time? Latency is how /long/ you (or the computer)
/waits/ for something. That defines it as a function of time.
Latency is of
On Wed, 13 Sep 2000, Ragnar Kjørstad wrote:
On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
If I may ask a potentially stupid question, how can request latency be
anything but a factor of time? Latency is how /long/ you (or the computer)
/waits/ for something. That
On Wed, Sep 13, 2000 at 08:08:51PM -0400, Giuliano Pochini wrote:
And if so, in what unit do you want to measure
latency if it isn't time?
I had a look at the new elevator. I hope I'm not wrong here... Requests
are added to the queue scanning it starting from the tail. When the
new
On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
Another potentially stupid question:
When the queue gets too long/old, new requests should be put in
a new queue to avoid starvation for the ones in the current
queue, right?
On Wed, Sep 13, 2000 at 08:08:12PM -0300, Rik van Riel wrote:
On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
Another potentially stupid question:
When the queue gets too long/old, new requests should be put in
a new queue
Alan Cox wrote:
> > time, but remember that there are two things measured in time here:
> > A. The time for the whole queue of requests to run (this is what Rik is
> > proposing using to throttle)
> > B. The time an average request takes to process.
>
> Your perceived latency is based
Hans Reiser wrote:
>
> I really think Rik has it right here. In particular, an MP3 player needs to be able
>to say, I have
> X milliseconds of buffer so make my worst case latency X milliseconds. The number
>of requests is
> the wrong metric, because the time required per request depends on
> time, but remember that there are two things measured in time here:
> A. The time for the whole queue of requests to run (this is what Rik is
> proposing using to throttle)
> B. The time an average request takes to process.
Your perceived latency is based entirely on A.
> If we limit
Alan Cox wrote:
> > Now, I see people trying to introduce the concept of elapsed time into
> > that fix, which smells strongly of hack. How will this hack be cobbled
>
> Actually my brain says that elapsed time based scheduling is the right thing
> to do.
No, Andrea is right here. The argument
Andrea Arcangeli wrote:
>
> On Tue, 12 Sep 2000, Martin Dalecki wrote:
>
> >First of all: In the case of the mp3 player and such there is already a
> >fine
> >proper way to give it better chances on getting it's job done smooth -
> >RT kernel sceduler priorities and proper IO buffering. I did
One important point on remirroring I did not mention in my post. In
NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
artificial starvation while remirring is going on. This was another
optimization we learned the hard way by trying numerous approaches to
the problem.
Jeff
Ed
Hi,
Geez, A simple comment on IRC can _really_ generate lots of feedback.
(There were over 50 messages about this in my queue - did not help
that some were duplicated three times ).
I made the comment because I remember back when the discussion was current
on linux kernel. I thought Jeff
On Tue, 12 Sep 2000, Martin Dalecki wrote:
>First of all: In the case of the mp3 player and such there is already a
>fine
>proper way to give it better chances on getting it's job done smooth -
>RT kernel sceduler priorities and proper IO buffering. I did something
>similiar
>to a GDI printer
> Why do you say it's not been fixed? Can you still reproduce hangs long as
> a write(2) can write? I certainly can't.
I cant reproduce long hangs. Im not seeing as good I/O throughput as before
but right now Im quite happy with the tradeoff. If someone can make it better
then Im happier still
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >Also, this possibility is /extremely/ remote, if not
> >impossible. Well, it could happen at one point in time,
>
> It's not impossible. Think when you run a backup of you home
> directory while you're
On Tue, 12 Sep 2000, Martin Dalecki wrote:
> Second: The concept of time can give you very very nasty
> behaviour in even cases. [integer arithmetic]
Point taken.
> Third: All you try to improve is the boundary case between an
> entierly overloaded system and a system which has a huge
On Tue, 12 Sep 2000, Jamie Lokier wrote:
>Sure the global system is slower. But the "interactive feel" is faster.
>If I type "find /" I want it to go quickly. But I still want Emacs to
You always want it to go quickly. But when you're in the blockdevice
layer you lost all the semantics of
On Tue, 12 Sep 2000, Chris Evans wrote:
>the elevator code. Keep it to a queue management system, and suddenly it
>scales to slow or fast devices without any gross device-type specific
>tuning.
Yep, that was the object.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, 12 Sep 2000, Rik van Riel wrote:
>But you don't. Transfer rate is very much dependant on the
>kind of load you're putting on the disk...
Transfer rate means `hdparm -t` in single user mode. Try it and you'll see
you'll get always the same result.
>Throughput really isn't that relevant
On Tue, 12 Sep 2000, Rik van Riel wrote:
>Why do you always come up with impossible examples?
That's not impossible. impossible != unlikely.
A more regular case is when you have an extremely fast device, were a 1/2
second latency is too much, using 100msec could be just enough to provide
good
> That problem: the original elevator code did not schedule I/O particularly
> fairly under certain I/O usage patterns. So it got fixed.
No it got hacked up a bit.
> Now, I see people trying to introduce the concept of elapsed time into
> that fix, which smells strongly of hack. How will this
On Tue, 12 Sep 2000, Alan Cox wrote:
> > Now, I see people trying to introduce the concept of elapsed time into
> > that fix, which smells strongly of hack. How will this hack be cobbled
>
> Actually my brain says that elapsed time based scheduling is the right
> thing to do. It certainly
Chris Evans wrote:
>
> On Tue, 12 Sep 2000, Hans Reiser wrote:
>
> > I really think Rik has it right here. In particular, an MP3 player
> > needs to be able to say, I have X milliseconds of buffer so make my
> > worst case latency X milliseconds. The number of requests is the
> > wrong
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >As an approximation, you could take the task that queues the
> >request. Only kswapd, kflushd and kupdate would be the "false
>
> That would probably be ok, but if we do that I prefer do it without
>
On Tue, 12 Sep 2000, Chris Evans wrote:
>like the task scheduler policies we have. For example, maybe we could flag
>a given process so that all it's I/O requests go to the head of the queue.
Yes. We can't do that at the moment because at the elevator layer we don't
know who is waiting for I/O
On Tue, 12 Sep 2000, Hans Reiser wrote:
> I really think Rik has it right here. In particular, an MP3 player
> needs to be able to say, I have X milliseconds of buffer so make my
> worst case latency X milliseconds. The number of requests is the
> wrong metric, because the time required per
I really think Rik has it right here. In particular, an MP3 player needs to be able
to say, I have
X milliseconds of buffer so make my worst case latency X milliseconds. The number of
requests is
the wrong metric, because the time required per request depends on disk geometry, disk
caching,
On Tue, 12 Sep 2000, Rik van Riel wrote:
> On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> > On Tue, 12 Sep 2000, Rik van Riel wrote:
> >
> > >Uhmmm, isn't the elevator about request /latency/ ?
> >
> > Yes, but definitely not absolute "time" latency.
> >
> > How do you get a 1msec latency
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >But you don't. Transfer rate is very much dependant on the
> >kind of load you're putting on the disk...
>
> Transfer rate means `hdparm -t` in single user mode. Try it and
> you'll see you'll get
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >We can already set different figures for different drives.
>
> Right.
>
> >Would it really be more than 30 minutes of work to put in
> >a different request # limit for each drive that automatically
>
Andrea Arcangeli wrote:
> >Andrea - latency is time measured and perceived. Doing it time based
> >seems to make reasonable sense. I grant you might want to play with
> >the weighting per [device]
Right. Perception.
> When you have a device that writes a request every two seconds you still
>
On Tue, 12 Sep 2000, Rik van Riel wrote:
>We can already set different figures for different drives.
Right.
>Would it really be more than 30 minutes of work to put in
>a different request # limit for each drive that automatically
>satisfies the latency specified by the user?
Note that if you
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >Uhmmm, isn't the elevator about request /latency/ ?
>
> Yes, but definitely not absolute "time" latency.
>
> How do you get a 1msec latency for a read request out of a
> blockdevice that writes 1
On Tue, 12 Sep 2000, Alan Cox wrote:
>Andrea - latency is time measured and perceived. Doing it time based seems to
>make reasonable sense. I grant you might want to play with the weighting per
When you have a device that writes a request every two seconds you still
want it not to seek all the
> Going in function of time is obviously wrong. A blockdevice can write 1
> request every two seconds or 1 request every msecond. You can't assume
> anything in function of time _unless_ you have per harddisk timing
> informations into the kernel.
Andrea - latency is time measured and perceived.
> in the queue is, and when that request is getting
> too old (say 1/2 second), we /stop/ all the others
> from entering their request into the queue (except
> if it can be merged with another request ???).
When you do the scan to decide where to insert the entry you dont consider
insertion
On Tue, 12 Sep 2000, Rik van Riel wrote:
>Uhmmm, isn't the elevator about request /latency/ ?
Yes, but definitely not absolute "time" latency.
How do you get a 1msec latency for a read request out of a blockdevice
that writes 1 request in 2 seconds? See?
That was one of the first issues I was
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >We simply keep track of how old the oldest request
> >in the queue is, and when that request is getting
> >too old (say 1/2 second), we /stop/ all the others
>
> Going in function of time is obviously
On Tue, 12 Sep 2000, Rik van Riel wrote:
>We simply keep track of how old the oldest request
>in the queue is, and when that request is getting
>too old (say 1/2 second), we /stop/ all the others
Going in function of time is obviously wrong. A blockdevice can write 1
request every two seconds
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
>
> >The large IO delays I'm seeing in certain tests have
> >been traced back to the /elevator/ code. I think I'll
>
> Actually the elevator works as in 2.2.15 (before any fix). The
> latency settings are
On Tue, 12 Sep 2000, Rik van Riel wrote:
>The large IO delays I'm seeing in certain tests have
>been traced back to the /elevator/ code. I think I'll
Actually the elevator works as in 2.2.15 (before any fix). The latency
settings are too high. They should be around 250 for reads and 500 for
Date:Tue, 12 Sep 2000 04:23:05 -0300 (BRST)
From: Rik van Riel <[EMAIL PROTECTED]>
I've just uploaded a new snapshot of my new VM for
2.4 to my home page, this version contains a
wakeup_kswapd() function (copied from wakeup_bdflush)
and should balance memory a bit
On Tue, 12 Sep 2000, Matthew Hawkins wrote:
> Very stable so far, and having Andrea's VM patches in (I usually
> didn't put them in) has made a noticeable difference - xmms has
> rarely skipped and things start faster and run smoother.
> Hopefully I'll see the same (or better) results from
1 - 100 of 143 matches
Mail list logo
