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
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.
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, 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
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, 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, 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 for a read request
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, 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
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 metric, because
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 works for
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 hack
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, 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 reserve
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 listening
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, 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
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 something
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 that
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 on
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 disk
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 entirely on
Considering there are a lot of people still using 2.0.x because they find it
more stable than the 2.2.x series, doesn't it make sense to give this
scalability to people who are already running SMP boxes on 2.2.x and who may
decide to use ReiserFS?
- Original Message -
From: "Andrea
On Mon, 11 Sep 2000, Andi Kleen wrote:
>BTW, there is a another optimization that could help reiserfs a lot
>on SMP settings: do a unlock_kernel()/lock_kernel() around the user
>copies. It is quite legal to do that (you have to handle sleeping
>anyways in case of a page fault), and it allows
On Mon, Sep 11, 2000 at 08:15:15AM -0400, Chris Mason wrote:
> LFS changes for filldir, reiserfs_readpage, and adds limit checking in
> file_write to make sure we don't go above 2GB (Andi Kleen). Also fixes
> include/linux/fs.h, which does not patch cleanly for 3.5.25 because of usb.
>
>
On Mon, 11 Sep 2000, Chris Mason wrote:
>reiserfs-3.5.25, this patch. I tested against pre3-aa2.
BTW, pre3-aa2 means 2.2.18pre2aa2.bz2 applyed on top of 2.2.18pre3.
>Note, you might see debugging messages about items moving during
>copy_from_user. These are safe, but I'm leaving them in for
On Mon, 11 Sep 2000, Andi Kleen wrote:
BTW, there is a another optimization that could help reiserfs a lot
on SMP settings: do a unlock_kernel()/lock_kernel() around the user
copies. It is quite legal to do that (you have to handle sleeping
anyways in case of a page fault), and it allows CPUs
1 - 100 of 101 matches
Mail list logo
