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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox