Hi!
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but i
Hi!
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but i
On Wed, May 23, 2001 at 05:51:50PM +, Scott Anderson wrote:
> David Weinehall wrote:
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays
On Thu, 24 May 2001, Rik van Riel wrote:
> > > > OK.. let's forget about throughput for a moment and consider
> > > > those annoying reports of 0 order allocations failing :)
> > >
> > > Those are ok. All failing 0 order allocations are either
> > > atomic allocations or GFP_BUFFER allocations.
On Thu, 24 May 2001, Mike Galbraith wrote:
> On Thu, 24 May 2001, Rik van Riel wrote:
> > On Thu, 24 May 2001, Mike Galbraith wrote:
> > > On Sun, 20 May 2001, Rik van Riel wrote:
> > >
> > > > Remember that inactive_clean pages are always immediately
> > > > reclaimable by __alloc_pages(), if you
On Thu, 24 May 2001, Rik van Riel wrote:
> On Thu, 24 May 2001, Mike Galbraith wrote:
> > On Sun, 20 May 2001, Rik van Riel wrote:
> >
> > > Remember that inactive_clean pages are always immediately
> > > reclaimable by __alloc_pages(), if you measured a performance
> > > difference by freeing pa
On Thu, 24 May 2001, Mike Galbraith wrote:
> On Sun, 20 May 2001, Rik van Riel wrote:
>
> > Remember that inactive_clean pages are always immediately
> > reclaimable by __alloc_pages(), if you measured a performance
> > difference by freeing pages in a different way I'm pretty sure
> > it's a side
On Sun, 20 May 2001, Rik van Riel wrote:
> Remember that inactive_clean pages are always immediately
> reclaimable by __alloc_pages(), if you measured a performance
> difference by freeing pages in a different way I'm pretty sure
> it's a side effect of something else. What that something
> else
David Weinehall wrote:
> IMVHO every developer involved in memory-management (and indeed, any
> software development; the authors of ntpd comes in mind here) should
> have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> luxury of a 486 with 8MB of RAM and 32MB of swap as a firew
>Time to hunt around for a 386 or 486 which is limited to such
>a small amount of RAM ;)
I've got an old knackered 486DX/33 with 8Mb RAM (in 30-pin SIMMs, woohoo!),
a flat CMOS battery, a 2Gb Maxtor HD that needs a low-level format every
year, and no case. It isn't running anything right now...
On Mon, 21 May 2001, David Weinehall wrote:
> IMVHO every developer involved in memory-management (and indeed, any
> software development; the authors of ntpd comes in mind here) should
> have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> luxury of a 486 with 8MB of RAM and 3
On Sun, May 20, 2001 at 11:54:09PM +0200, Pavel Machek wrote:
> Hi!
>
> > > You're right. It should never dump too much data at once. OTOH, if
> > > those cleaned pages are really old (front of reclaim list), there's no
> > > value in keeping them either. Maybe there should be a slow bleed for
Hi!
> > You're right. It should never dump too much data at once. OTOH, if
> > those cleaned pages are really old (front of reclaim list), there's no
> > value in keeping them either. Maybe there should be a slow bleed for
> > mostly idle or lightly loaded conditions.
>
> If you don't think i
Hi,
On Sun, May 20, 2001 at 07:04:31AM -0300, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
> >
> > Looking at the locking and trying to think SMP (grunt) though, I
> > don't like the thought of taking two locks for each page until
>
> > 100%. The data in that block is toast
On Sun, 20 May 2001, Marcelo Tosatti wrote:
> On Sat, 19 May 2001, Mike Galbraith wrote:
>
> > @@ -1054,7 +1033,7 @@
> > if (!zone->size)
> > continue;
> >
> > - while (zone->free_pages < zone->pages_low) {
On Sun, 20 May 2001, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
> > On 20 May 2001, Zlatko Calusic wrote:
>
> > > Also in all recent kernels, if the machine is swapping, swap cache
> > > grows without limits and is hard to recycle, but then again that is
> > > a known proble
On Sat, 19 May 2001, Mike Galbraith wrote:
> @@ -1054,7 +1033,7 @@
> if (!zone->size)
> continue;
>
> - while (zone->free_pages < zone->pages_low) {
> + while (zone->free
On Sun, 20 May 2001, Mike Galbraith wrote:
> On 20 May 2001, Zlatko Calusic wrote:
> > Also in all recent kernels, if the machine is swapping, swap cache
> > grows without limits and is hard to recycle, but then again that is
> > a known problem.
>
> This one bugs me. I do not see that and can'
On Sun, 20 May 2001, Mike Galbraith wrote:
> > Also in all recent kernels, if the machine is swapping, swap cache
> > grows without limits and is hard to recycle, but then again that is
> > a known problem.
>
> This one bugs me. I do not see that and can't understand why.
To throw away dirty
On 20 May 2001, Zlatko Calusic wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> >
> > > That's the main problem with static parameters. The problem you are
> > > trying to solve is fundamentally dynamic in most cases (which is
On Sun, 20 May 2001, Ingo Oeser wrote:
> On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
> > I'm not sure why that helps. I didn't put it in as a trick or
> > anything though. I put it in because it didn't seem like a
> > good idea to ever have more cleaned pages than free pages
Mike Galbraith <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
>
> > That's the main problem with static parameters. The problem you are
> > trying to solve is fundamentally dynamic in most cases (which is also
> > why magic numbers tend to suck in the VM.)
On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
> I'm not sure why that helps. I didn't put it in as a trick or
> anything though. I put it in because it didn't seem like a
> good idea to ever have more cleaned pages than free pages at a
> time when we're yammering for help.. so
On Sun, 20 May 2001, Mike Galbraith wrote:
> but ;-)
>
> Looking at the locking and trying to think SMP (grunt) though, I
> don't like the thought of taking two locks for each page until
> 100%. The data in that block is toast anyway. A big hairy SMP
> box has to feel reclaim_page(). (they pr
On Sun, 20 May 2001, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
>
> > You're right. It should never dump too much data at once. OTOH, if
> > those cleaned pages are really old (front of reclaim list), there's no
> > value in keeping them either. Maybe there should be a sl
On Sun, 20 May 2001, Mike Galbraith wrote:
> You're right. It should never dump too much data at once. OTOH, if
> those cleaned pages are really old (front of reclaim list), there's no
> value in keeping them either. Maybe there should be a slow bleed for
> mostly idle or lightly loaded condit
On Sun, 20 May 2001, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
> >
> > I'm not sure why that helps. I didn't put it in as a trick or
> > anything though. I put it in because it didn't seem like a
> > good idea to ever have more cleaned pages than free pages at a
> > time
On Sun, 20 May 2001, Mike Galbraith wrote:
> On Sat, 19 May 2001, Rik van Riel wrote:
> > On Sat, 19 May 2001, Mike Galbraith wrote:
> > > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> > >
> > > > That's the main problem with static parameters. The problem you are
> > > > trying to solve is fu
On Sun, 20 May 2001, Dieter Nützel wrote:
> > > Three back to back make -j 30 runs for three different kernels.
> > > Swap cache numbers are taken immediately after last completion.
> >
> > The performance increase is nice, though. Do you see similar
> > changes in different kinds of workloads ?
On Sat, 19 May 2001, Rik van Riel wrote:
> On Sat, 19 May 2001, Mike Galbraith wrote:
> > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> >
> > > That's the main problem with static parameters. The problem you are
> > > trying to solve is fundamentally dynamic in most cases (which is also
> > >
> > Three back to back make -j 30 runs for three different kernels.
> > Swap cache numbers are taken immediately after last completion.
>
> The performance increase is nice, though. Do you see similar
> changes in different kinds of workloads ?
I you have a patch against 2.4.4-ac11 I will do som
On Sat, 19 May 2001, Mike Galbraith wrote:
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
>
> > That's the main problem with static parameters. The problem you are
> > trying to solve is fundamentally dynamic in most cases (which is also
> > why magic numbers tend to suck in the VM.)
>
> Magi
Hi,
On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> That's the main problem with static parameters. The problem you are
> trying to solve is fundamentally dynamic in most cases (which is also
> why magic numbers tend to suck in the VM.)
Magic numbers might be sucking some performance right no
33 matches
Mail list logo
