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 merg
> 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 ju
[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 i
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 ye
[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.
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 Labs
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 sa
> >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
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 that
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 Wed, 13 Sep 2000, Giuliano Pochini wrote:
>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 request if found in-order with ad existing one, it's inserted int
Right so that it works in O(1) if you'
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
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
> ne
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. T
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 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 el
> > 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 reque
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 y
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 s
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 app
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 s
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 list:
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
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 sort
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 o
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. F
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, detaill
> 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. A
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 en
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 d
> 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 so
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 the idea Jeff Merkey
presented? It seems to work well for Netware, so
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 dr
> 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, 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 mp3. Both `tar` and `xmms` will read the same file
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 l
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 reser
On Tue, 12 Sep 2000, Alan Cox wrote:
>> 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.
Why do you say it's not been fixed? Can you still reproduce hangs long as
a write(2) can w
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 linux-k
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 h
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 t
On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> 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
> 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 ha
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
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,
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
> gue
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 c
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 re
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, e
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
On Mon, 11 Sep 2000, Andi Kleen wrote:
>Given, but adding the unlock_kernel() does not really need much effort,
>it is a very cheap (programmer time wise) optimization.
Well, since there seems to be interest in this (and it's indeed very cheap
programmer time wise :) I will try to add such SMP o
On Mon, Sep 11, 2000 at 04:44:21PM +0200, Andrea Arcangeli wrote:
> On Mon, 11 Sep 2000, Michael T. Babcock wrote:
>
> >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 wh
On Mon, 11 Sep 2000, Michael T. Babcock wrote:
>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
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 Arcang
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 CP
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.
>
> Note,
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
66 matches
Mail list logo
