From: Andrew Morton <akpm@osdl.org>
To: Rik van Riel <riel@redhat.com>
Cc: cw@f00f.org, piggin@cyberone.com.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vm-fix-all_zones_ok (was Re: 2.6.3-mm3)
Date: Tue, 24 Feb 2004 14:36:18 -0800 [thread overview]
Message-ID: <20040224143618.368dfdca.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0402241553550.21522-100000@chimarrao.boston.redhat.com>
Rik van Riel <riel@redhat.com> wrote:
>
> On Tue, 24 Feb 2004, Andrew Morton wrote:
> > Chris Wedgwood <cw@f00f.org> wrote:
> > > On Tue, Feb 24, 2004 at 03:11:40PM +1100, Nick Piggin wrote:
> > >
> > > > Out of interest, what is the worst you can make it do with
> > > > contrived cases?
> > >
> > > 700MB slab used.
> >
> > Sigh. There is absolutely nothing wrong with having a large slab cache.
> > And there is nothing necessarily right about having a small one.
>
> Could it be that the lower zone protection stuff simply means
> that Chris's system only ever allocates page cache and anonymous
> memory from his 600 MB highmem, leaving the 900 MB lowmem for
> the slab cache to roam freely ?
The lower-zone protection code will only preserve an extra megabyte or so
of the normal zone in response to __GFP_HIGHMEM allocations, so it won't be
coming into play here.
I'd prefer to replace the lower-zone/incremental-min code with 2.4's
watermark code. It's pretty much equivalent, but makes the calculations
once-only and it is easier to observe and understand its effects. But
there's too much work going on in there to make this change at present.
> I guess highmem allocations really should put some pressure on
> lowmem, even when there is enough lowmem free, because otherwise
> you end up effectively not using half of the memory on 1.5-2 GB
> systems for paging ...
Yup. With the current -mm patches the reclaim rate from lowmem and highmem
is nicely proportional to each zone's size for pagecache-heavy workloads.
For lowmem-intensive workloads the reclaim rate from lowmem is higher, as
one would expect. It seems to be working OK now.
next prev parent reply other threads:[~2004-02-24 22:38 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-23 1:22 2.6.3-mm3 Andrew Morton
2004-02-23 1:43 ` 2.6.3-mm3 Nick Piggin
2004-02-23 1:55 ` 2.6.3-mm3 Andrew Morton
2004-02-23 2:02 ` 2.6.3-mm3 Nick Piggin
2004-02-23 2:51 ` 2.6.3-mm3 Nick Piggin
2004-02-23 3:04 ` 2.6.3-mm3 Nick Piggin
2004-02-23 8:08 ` 2.6.3-mm3 Nick Piggin
2004-02-23 8:48 ` [PATCH] vm-fix-all_zones_ok (was Re: 2.6.3-mm3) Nick Piggin
2004-02-23 8:59 ` Andrew Morton
2004-02-23 9:21 ` Nick Piggin
2004-02-23 9:24 ` Andrew Morton
2004-02-23 16:23 ` Bill Davidsen
2004-02-23 22:47 ` Chris Wedgwood
2004-02-24 4:11 ` Nick Piggin
2004-02-24 9:12 ` Chris Wedgwood
2004-02-24 9:22 ` Andrew Morton
2004-02-24 9:30 ` Chris Wedgwood
2004-02-24 9:37 ` Andrew Morton
2004-02-24 20:55 ` Rik van Riel
2004-02-24 22:36 ` Andrew Morton [this message]
2004-02-24 22:41 ` Rik van Riel
2004-02-23 2:19 ` 2.6.3-mm3 Christoph Hellwig
2004-02-23 2:52 ` 2.6.3-mm3 Joshua Kwan
2004-02-23 3:34 ` 2.6.3-mm3 Joshua Kwan
2004-02-23 18:09 ` [patch] 2.6.3-mm3: ALSA miXart driver doesn't compile Adrian Bunk
2004-02-23 18:58 ` 2.6.3-mm3 (compile stats) John Cherry
2004-02-23 20:00 ` Sam Ravnborg
2004-02-24 22:22 ` 2.6.3-mm3 Mike Fedyk
2004-02-24 22:30 ` 2.6.3-mm3 Andrew Morton
2004-02-25 21:27 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 1:06 ` 2.6.3-mm3 Nick Piggin
2004-02-26 1:18 ` 2.6.3-mm3 Marc-Christian Petersen
2004-02-26 1:28 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 1:32 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 1:52 ` 2.6.3-mm3 Nick Piggin
2004-02-26 2:34 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 2:40 ` 2.6.3-mm3 Nick Piggin
2004-02-26 2:48 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 3:05 ` 2.6.3-mm3 Nick Piggin
2004-02-26 3:19 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 3:29 ` 2.6.3-mm3 Nick Piggin
2004-02-26 4:08 ` 2.6.3-mm3 Mike Fedyk
2004-02-26 4:56 ` 2.6.3-mm3 Mike Fedyk
2004-02-27 19:02 ` 2.6.3-mm3 Mike Fedyk
2004-02-27 21:57 ` 2.6.3-mm3 Nick Piggin
2004-02-25 0:26 ` 2.6.3-mm3 hangs on boot x440 (scsi?) john stultz
2004-02-25 1:06 ` Andrew Morton
2004-02-25 1:22 ` john stultz
2004-02-25 1:27 ` john stultz
2004-02-25 1:48 ` Andrew Morton
2004-02-25 22:15 ` john stultz
2004-02-26 14:40 ` Go Taniguchi
2004-02-26 21:26 ` john stultz
2004-02-26 23:02 ` john stultz
2004-02-26 23:15 ` Matthew Wilcox
2004-02-27 0:14 ` john stultz
2004-02-27 0:58 ` john stultz
2004-02-27 2:25 ` john stultz
2004-02-25 1:15 ` [PATCH 2.6.3-mm3] serialize_writeback_fdatawait patch Daniel McNeil
2004-02-25 1:43 ` Andrew Morton
2004-02-25 22:56 ` Daniel McNeil
2004-02-25 2:51 ` 2.6.3-mm3 Mike Fedyk
2004-02-25 3:09 ` 2.6.3-mm3 Andrew Morton
2004-02-25 3:34 ` 2.6.3-mm3 Mike Fedyk
2004-02-25 10:47 ` 2.6.3-mm3 sometimes freeze on "sync" Helge Hafting
2004-02-25 9:39 ` Andrew Morton
2004-02-26 8:49 ` Helge Hafting
2004-02-27 14:49 ` Alexander Hoogerhuis
2004-02-27 23:34 ` 2.6.3-mm3 john stultz
2004-02-28 0:06 ` 2.6.3-mm3 Andrew Morton
2004-02-28 2:48 ` 2.6.3-mm3 (ioremap failure w/ _X86_4G and _NUMA) john stultz
2004-02-28 3:18 ` Dave Hansen
2004-02-28 4:34 ` Martin J. Bligh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040224143618.368dfdca.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=piggin@cyberone.com.au \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.