On Tue, 6 Mar 2001, Marcelo Tosatti wrote:
> On Fri, 2 Mar 2001, Mike Galbraith wrote:
>
> > On Thu, 1 Mar 2001, Rik van Riel wrote:
> >
> > > > > The merging at the elevator level only works if the requests sent to
> > > > > it are right next to each other on disk. This means that randomly
> > >
On Fri, 2 Mar 2001, Mike Galbraith wrote:
> On Thu, 1 Mar 2001, Rik van Riel wrote:
>
> > > > The merging at the elevator level only works if the requests sent to
> > > > it are right next to each other on disk. This means that randomly
> > > > sending stuff to disk really DOES DESTROY PERFORM
On 1 Mar 2001, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Rik van Riel <[EMAIL PROTECTED]> wrote:
> >
> >I haven't tested it yet for a number of reasons. The most
> >important one is that the FreeBSD people have been playing
> >with this thing for a few years now and Matt Dillon ha
On Thu, 1 Mar 2001, Rik van Riel wrote:
> > > The merging at the elevator level only works if the requests sent to
> > > it are right next to each other on disk. This means that randomly
> > > sending stuff to disk really DOES DESTROY PERFORMANCE and there's
> > > nothing the elevator could ever
On Thu, 1 Mar 2001, Chris Evans wrote:
> Oh dear.. not more "vm design by waving hands in the air". Come on people,
> improve the vm by careful profiling, tweaking and benching, not by
> throwing random patches in that seem cool in theory.
Excuse me.. we're trying to have a _constructive_ conver
In article <[EMAIL PROTECTED]>,
Rik van Riel <[EMAIL PROTECTED]> wrote:
>
>I haven't tested it yet for a number of reasons. The most
>important one is that the FreeBSD people have been playing
>with this thing for a few years now and Matt Dillon has
>told me the result of their tests ;)
Note tha
On Thu, 1 Mar 2001, Chris Evans wrote:
> On Thu, 1 Mar 2001, Rik van Riel wrote:
>
> > True. I think we want something in-between our ideas...
> ^^^
> > a while. This should make it possible for the disk reads to
> ^^
>
> Oh dear.. not more "vm design by waving hand
On Thu, 1 Mar 2001, Chris Evans wrote:
>
> On Thu, 1 Mar 2001, Rik van Riel wrote:
>
> > True. I think we want something in-between our ideas...
> ^^^
> > a while. This should make it possible for the disk reads to
> ^^
>
> Oh dear.. not more "vm design by wavi
On Thu, 1 Mar 2001, Rik van Riel wrote:
> True. I think we want something in-between our ideas...
^^^
> a while. This should make it possible for the disk reads to
^^
Oh dear.. not more "vm design by waving hands in the air". Come on people,
improve the vm by car
> Except that your code throws the random junk at the elevator all
> the time, while my code only bothers the elevator every once in
> a while. This should make it possible for the disk reads to
> continue with less interruptions.
Think about it this way, throwing the stuff at the I/O layer is sa
> There is no mechanysm in place that ensures that dirty pages can't
> get out of control, and they do in fact get out of control, and it
> is exaserbated (mho) by attempting to define 'too much I/O' without
> any information to base this definition upon.
I think this is a good point. If you do '
Rik van Riel wrote:
[ ... ]
> Except that your code throws the random junk at the elevator all
> the time, while my code only bothers the elevator every once in
> a while. This should make it possible for the disk reads to
> continue with less interruptions.
>
Couldn't agree with you m
On Thu, 1 Mar 2001, Mike Galbraith wrote:
> On Thu, 1 Mar 2001, Rik van Riel wrote:
> > On Thu, 1 Mar 2001, Mike Galbraith wrote:
> No no no and again no (perhaps I misread that bit). But otoh,
> you haven't tested the patch I sent in good faith. I sent it
> because I have thought about it. I
On Thu, 1 Mar 2001, Rik van Riel wrote:
> On Thu, 1 Mar 2001, Mike Galbraith wrote:
> > On Wed, 28 Feb 2001, Rik van Riel wrote:
> > > On Wed, 28 Feb 2001, Marcelo Tosatti wrote:
> > > > On Wed, 28 Feb 2001, Mike Galbraith wrote:
> > >
> > > > > That's one reason I tossed it out. I don't _think_
On Thu, 1 Mar 2001, Mike Galbraith wrote:
> On Wed, 28 Feb 2001, Rik van Riel wrote:
> > On Wed, 28 Feb 2001, Marcelo Tosatti wrote:
> > > On Wed, 28 Feb 2001, Mike Galbraith wrote:
> >
> > > > That's one reason I tossed it out. I don't _think_ it should have any
> > > > negative effect on other
On Wed, 28 Feb 2001, Rik van Riel wrote:
> On Wed, 28 Feb 2001, Marcelo Tosatti wrote:
> > On Wed, 28 Feb 2001, Mike Galbraith wrote:
>
> > > That's one reason I tossed it out. I don't _think_ it should have any
> > > negative effect on other loads, but a test run might find otherwise.
> >
> > W
Rik van Riel wrote:
>
> Another solution would be to do some more explicit IO clustering and
> only flush _large_ clusters ... no need to invoke extra disk seeks
> just to free a single page, unless you only have single pages left.
Hi Rik,
Yes, clustering IO at the higher level can improve per
On Wed, 28 Feb 2001, Marcelo Tosatti wrote:
> On Wed, 28 Feb 2001, Mike Galbraith wrote:
> > That's one reason I tossed it out. I don't _think_ it should have any
> > negative effect on other loads, but a test run might find otherwise.
>
> Writes are more expensive than reads. Apart from the agg
On Wed, 28 Feb 2001, Marcelo Tosatti wrote:
> On Wed, 28 Feb 2001, Mike Galbraith wrote:
>
> > > > Have you tried to use SWAP_SHIFT as 4 instead of 5 on a stock 2.4.2-ac5 to
> > > > see if the system still swaps out too much?
> > >
> > > Not yet, but will do.
>
> But what about swapping behaviour
On Wed, 28 Feb 2001, Mike Galbraith wrote:
> > > Have you tried to use SWAP_SHIFT as 4 instead of 5 on a stock 2.4.2-ac5 to
> > > see if the system still swaps out too much?
> >
> > Not yet, but will do.
But what about swapping behaviour?
It still swaps too much?
-
To unsubscribe from this
On Wed, 28 Feb 2001, Mike Galbraith wrote:
> On Tue, 27 Feb 2001, Marcelo Tosatti wrote:
>
> > On Tue, 27 Feb 2001, Mike Galbraith wrote:
> >
> > > What the patch does is simply to push I/O as fast as we can.. we're
> > > by definition I/O bound and _can't_ defer it under any circumstance,
> >
> > Have you tried to use SWAP_SHIFT as 4 instead of 5 on a stock 2.4.2-ac5 to
> > see if the system still swaps out too much?
>
> Not yet, but will do.
Didn't help. (It actually reduced throughput a little)
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Tue, 27 Feb 2001, Marcelo Tosatti wrote:
> On Tue, 27 Feb 2001, Mike Galbraith wrote:
>
> > What the patch does is simply to push I/O as fast as we can.. we're
> > by definition I/O bound and _can't_ defer it under any circumstance,
> > for in this direction lies constipation. The only thing
On Tue, 27 Feb 2001, Mike Galbraith wrote:
> On Tue, 27 Feb 2001, Rik van Riel wrote:
>
> > On Tue, 27 Feb 2001, Mike Galbraith wrote:
> >
> > > Attempting to avoid doing I/O has been harmful to throughput here
> > > ever since the queueing/elevator woes were fixed. Ever since then,
> > > tossi
On Tue, 27 Feb 2001, Rik van Riel wrote:
> On Tue, 27 Feb 2001, Mike Galbraith wrote:
>
> > Attempting to avoid doing I/O has been harmful to throughput here
> > ever since the queueing/elevator woes were fixed. Ever since then,
> > tossing attempts at avoidance has improved throughput markedly.
On Tue, 27 Feb 2001, Mike Galbraith wrote:
> Attempting to avoid doing I/O has been harmful to throughput here
> ever since the queueing/elevator woes were fixed. Ever since then,
> tossing attempts at avoidance has improved throughput markedly.
>
> IMHO, any patch which claims to improve through
Hi,
Attempting to avoid doing I/O has been harmful to throughput here
ever since the queueing/elevator woes were fixed. Ever since then,
tossing attempts at avoidance has improved throughput markedly.
IMHO, any patch which claims to improve throughput via code deletion
should be worth a little e
27 matches
Mail list logo
