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
30 matches
Mail list logo
