From: Andrea Arcangeli <andrea@suse.de>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@osdl.org>
Subject: Re: VM fixes [2/4]
Date: Mon, 3 Jan 2005 17:30:46 +0100 [thread overview]
Message-ID: <20050103163046.GY5164@dualathlon.random> (raw)
In-Reply-To: <20050103122518.GF29158@logos.cnet>
On Mon, Jan 03, 2005 at 10:25:18AM -0200, Marcelo Tosatti wrote:
> On Sun, Jan 02, 2005 at 05:32:36PM +0100, Andrea Arcangeli wrote:
> > On Fri, Dec 31, 2004 at 08:12:42AM +1100, Nick Piggin wrote:
> > > Andrea Arcangeli wrote:
> > > >This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > > >invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> > > >like google (especially without swap) on x86 with >1G of ram, but it's
> > > >needed in all sort of workloads with lots of ram on x86, it's also
> > > >needed on x86-64 for dma allocations. This brings 2.6 in sync with
> > > >latest 2.4.2x.
> > > >
> > >
> > > This looks OK to me. It really simplifies the code there a lot too.
> > >
> > > The only questions I have are: should it be on by default? I don't think
> > > we ever reached an agreement. I'd say yes, after a run in -mm because it
> > > does potentially fix corner cases where lower zones get filled with un-
> > > freeable memory which could have been satisfied with higher zones.
> >
> > Great, thanks for the review! I definitely agree it should be on by
> > default, I already had an hang report that was solved by more recent
> > kernels and that probably can only be explained by lowmem_reserve since
> > there aren't other mm changes in 2.6.5 based trees.
> >
> > > And second, any chance you could you port it to the mm patches already in
> > > -mm? Won't be a big job, just some clashes in __alloc_pages...
> >
> > I already had to port to 2.6.5 too, and that's enough for now unless I
> > first get a positive ack that it will be merged (if I hadn't more
> > interesting things to develop, I would be happily porting it).
>
> I believe it can be accepted easily if you change the variable names
> from protection to lowmem_reserve.
>
> Is there a need for that or its just your taste? :)
The naming is in sync with 2.4, I called that feature lowmem_reserve
when I wrote it. Protection doesn't actually mean anything. Memory
protection, mprotect, what?
The object of the feature is to reserve lower memory in function of the
classzone allocation, and in function of the zone we're allocating from.
So lowmem_reserve sounds a much better name. And it wasn't me to change
it, it was the 2.6 kernel calling it differently in the first place.
Note that at first 2.6 was doing stuff very differently from 2.4 too
(and it wasn't working right infact). Now it's in perfect sync with the 2.4
algorightm I wrote originally and so I thought it would be much cleaner
to call it the same way as 2.4, which is more self explanatory too.
prev parent reply other threads:[~2005-01-03 16:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-24 17:35 VM fixes [2/4] Andrea Arcangeli
2004-12-30 21:12 ` Nick Piggin
2005-01-02 16:32 ` Andrea Arcangeli
2005-01-03 12:25 ` Marcelo Tosatti
2005-01-03 16:30 ` Andrea Arcangeli [this message]
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=20050103163046.GY5164@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=nickpiggin@yahoo.com.au \
--cc=tglx@linutronix.de \
/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