On Mon, 18 Jun 2001, Daniel Phillips wrote:
> On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
> > It _juuust_ so happens that I was tinkering... what do you think of
> > something like the below? (and boy do I ever wonder what a certain
> > box doing slrn stuff thinks of it.. hint hint;)
>
>
On Sunday 17 June 2001 12:05, Mike Galbraith wrote:
> It _juuust_ so happens that I was tinkering... what do you think of
> something like the below? (and boy do I ever wonder what a certain
> box doing slrn stuff thinks of it.. hint hint;)
It's too subtle for me ;-) (Not shy about sying that b
On Sun, 17 Jun 2001 [EMAIL PROTECTED] wrote:
> On Sun, Jun 17, 2001 at 12:05:10PM +0200, Mike Galbraith wrote:
> >
> > It _juuust_ so happens that I was tinkering... what do you think of
> > something like the below? (and boy do I ever wonder what a certain
> > box doing slrn stuff thinks of it.
On Sun, Jun 17, 2001 at 12:05:10PM +0200, Mike Galbraith wrote:
>
> It _juuust_ so happens that I was tinkering... what do you think of
> something like the below? (and boy do I ever wonder what a certain
> box doing slrn stuff thinks of it.. hint hint;)
>
I'm sorry to say this box doesn't real
On Saturday 16 June 2001 23:54, Rik van Riel wrote:
> On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > > Does the patch below do anything good for your laptop? ;)
> >
> > I'll wait for the next one ;-)
>
> OK, here's one which isn't reversed and should work ;))
>
> --- fs/buffer.c.orig Sat Jun 16
On Sat, 16 Jun 2001, Daniel Phillips wrote:
> On Saturday 16 June 2001 23:06, Rik van Riel wrote:
> > On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > > As a side note, the good old multisecond delay before bdflush kicks in
> > > doesn't really make a lot of sense - when bandwidth is available the
On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > Does the patch below do anything good for your laptop? ;)
>
> I'll wait for the next one ;-)
OK, here's one which isn't reversed and should work ;))
--- fs/buffer.c.origSat Jun 16 18:05:29 2001
+++ fs/buffer.c Sat Jun 16 18:05:15 2001
@@ -255
On Saturday 16 June 2001 23:06, Rik van Riel wrote:
> On Sat, 16 Jun 2001, Daniel Phillips wrote:
> > As a side note, the good old multisecond delay before bdflush kicks in
> > doesn't really make a lot of sense - when bandwidth is available the
> > filesystem-initiated writeouts should happen rig
On Sat, 16 Jun 2001, Rik van Riel wrote:
Oops, I did something stupid and the patch is reversed ;)
> --- buffer.c.orig Sat Jun 16 18:05:15 2001
> +++ buffer.c Sat Jun 16 18:05:29 2001
> @@ -2550,8 +2550,7 @@
> if the current bh is not yet timed out,
>
On Sat, 16 Jun 2001, Daniel Phillips wrote:
> In other words, any episode of pageouts is followed immediately by a
> short episode of preemptive cleaning.
linux/mm/vmscan.c::page_launder(), around line 666:
/* Let bdflush take care of the rest. */
wakeup_bdflush(0
On Friday 15 June 2001 17:23, Pavel Machek wrote:
> Hi!
>
> > Roger> It does if you are running on a laptop. Then you do not want
> > Roger> the pages go out all the time. Disk has gone too sleep, needs
> > Roger> to start to write a few pages, stays idle for a while, goes to
> > Roger> sleep, a f
Hi!
> Roger> It does if you are running on a laptop. Then you do not want
> Roger> the pages go out all the time. Disk has gone too sleep, needs
> Roger> to start to write a few pages, stays idle for a while, goes to
> Roger> sleep, a few more pages, ...
>
> That could be handled by a metric whi
Mark Hahn wrote:
> > Disk speed is difficult. I may enable and disable swap on any number of
> ...
> > You may be able to get some useful approximations, but you
> > will probably not be able to get good numbers in all cases.
>
> a useful approximation would be simply an idle flag.
> for instan
On Thu, 14 Jun 2001, Roger Larsson wrote:
> On Thursday 14 June 2001 10:47, Daniel Phillips wrote:
> > On Thursday 14 June 2001 05:16, Rik van Riel wrote:
> > > On Wed, 13 Jun 2001, Tom Sightler wrote:
> > > > Quoting Rik van Riel <[EMAIL PROTECTED]>:
> > > > > After the initial burst, the system
On Thu, 14 Jun 2001, John Stoffel wrote:
> Rik> There's another issue. If dirty data is written out in small
> Rik> bunches, that means we have to write out the dirty data more
> Rik> often.
>
> What do you consider a small bunch? 32k? 1Mb? 1% of buffer space?
> I don't see how delaying write
Rik> There's another issue. If dirty data is written out in small
Rik> bunches, that means we have to write out the dirty data more
Rik> often.
What do you consider a small bunch? 32k? 1Mb? 1% of buffer space?
I don't see how delaying writes until the buffer is almost full really
helps us.
On Thu, 14 Jun 2001, John Stoffel wrote:
> That could be handled by a metric which says if the disk is spun down,
> wait until there is more memory pressure before writing. But if the
> disk is spinning, we don't care, you should start writing out buffers
> at some low rate to keep the pressure
Roger> It does if you are running on a laptop. Then you do not want
Roger> the pages go out all the time. Disk has gone too sleep, needs
Roger> to start to write a few pages, stays idle for a while, goes to
Roger> sleep, a few more pages, ...
That could be handled by a metric which says if the d
On Thursday 14 June 2001 10:47, Daniel Phillips wrote:
> On Thursday 14 June 2001 05:16, Rik van Riel wrote:
> > On Wed, 13 Jun 2001, Tom Sightler wrote:
> > > Quoting Rik van Riel <[EMAIL PROTECTED]>:
> > > > After the initial burst, the system should stabilise,
> > > > starting the writeout of p
On Thursday 14 June 2001 17:10, John Stoffel wrote:
> >> The file _could_ be a temporary file, which gets removed before
> >> we'd get around to writing it to disk. Sure, the chances of this
> >> happening with a single file are close to zero, but having 100MB
> >> from 200 different temp files on
> > Would it be possible to maintain a dirty-rate count
> > for the dirty buffers?
> >
> > For example, we it is possible to figure an approximate
> > disk subsystem speed from most of the given information.
>
> Disk speed is difficult. I may enable and disable swap on any number of
...
> You m
>> The file _could_ be a temporary file, which gets removed before
>> we'd get around to writing it to disk. Sure, the chances of this
>> happening with a single file are close to zero, but having 100MB
>> from 200 different temp files on a shell server isn't unreasonable
>> to expect.
Daniel> T
Laramie Leavitt wrote:
> Would it be possible to maintain a dirty-rate count
> for the dirty buffers?
>
> For example, we it is possible to figure an approximate
> disk subsystem speed from most of the given information.
Disk speed is difficult. I may enable and disable swap on any number of
v
On Thursday 14 June 2001 05:16, Rik van Riel wrote:
> On Wed, 13 Jun 2001, Tom Sightler wrote:
> > Quoting Rik van Riel <[EMAIL PROTECTED]>:
> > > After the initial burst, the system should stabilise,
> > > starting the writeout of pages before we run low on
> > > memory. How to handle the initial
On Wed, 13 Jun 2001, Rik van Riel wrote:
> On Wed, 13 Jun 2001, Tom Sightler wrote:
>
> > 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb Ethernet,
> > close to wire speed). At this point Linux has yet to write the first byte to
> > disk. OK, this might be an exaggerated,
On Behalf Of Rik van Riel
> On Wed, 13 Jun 2001, Tom Sightler wrote:
> > Quoting Rik van Riel <[EMAIL PROTECTED]>:
> >
> > > After the initial burst, the system should stabilise,
> > > starting the writeout of pages before we run low on
> > > memory. How to handle the initial burst is something
>
On Wed, 13 Jun 2001, Tom Sightler wrote:
> Quoting Rik van Riel <[EMAIL PROTECTED]>:
>
> > After the initial burst, the system should stabilise,
> > starting the writeout of pages before we run low on
> > memory. How to handle the initial burst is something
> > I haven't figured out yet ... ;)
>
Quoting Mark Hahn <[EMAIL PROTECTED]>:
> > 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb
> Ethernet,
> > close to wire speed). At this point Linux has yet to write the first
> byte to
> > disk. OK, this might be an exaggerated, but very little disk activity
> has
> > occ
Quoting Rik van Riel <[EMAIL PROTECTED]>:
> After the initial burst, the system should stabilise,
> starting the writeout of pages before we run low on
> memory. How to handle the initial burst is something
> I haven't figured out yet ... ;)
Well, at least I know that this is expected with the V
On Wed, 13 Jun 2001, Tom Sightler wrote:
> 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb Ethernet,
> close to wire speed). At this point Linux has yet to write the first byte to
> disk. OK, this might be an exaggerated, but very little disk activity has
> occured on my l
Hi All,
I have been using the 2.4.x kernels since the 2.4.0-test days on my Dell 5000e
laptop with 320MB of RAM and have experienced first hand many of the problems
other users have reported with the VM system in 2.4. Most of these problems
have been only minor anoyances and I have continued tes
31 matches
Mail list logo
