From: David Miller <davem@davemloft.net>
To: heiko.carstens@de.ibm.com
Cc: mel@csn.ul.ie, kamezawa.hiroyu@jp.fujitsu.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
sparclinux@vger.kernel.org
Subject: Re: HOLES_IN_ZONE...
Date: Thu, 05 Feb 2009 15:44:03 -0800 (PST) [thread overview]
Message-ID: <20090205.154403.200370311.davem@davemloft.net> (raw)
In-Reply-To: <20090205090016.6197d588@osiris.boeblingen.de.ibm.com>
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Thu, 5 Feb 2009 09:00:16 +0100
> On Wed, 04 Feb 2009 22:26:51 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
> > Later this HOLES_IN_ZONE requirement was removed on s390 by commit:
> >
> > commit 9f4b0ba81f158df459fa2cfc98ab1475c090f29c
> > Author: Heiko Carstens <heiko.carstens@de.ibm.com>
> > Date: Sat Jan 26 14:11:02 2008 +0100
> >
> > [S390] Get rid of HOLES_IN_ZONE requirement.
>
> This just made sure that all zones start on a MAX_ORDER boundary and
> just leaves memory that doesn't fit unused. So the requirement for
> HOLES_IN_ZONE went away.
>
> Later I reduced MAX_ORDER to 9 on s390, so we don't leave large
> portions of memory unused.
Isn't is easier to just make sure your vmemmap mappings extend to such
boundaries, whether they contain available memory or not?
That's the only requirement you have to satisfy to avoid having to
specify HOLES_IN_ZONE. You don't have to have memory there, just
some vmmemmap page structs have to be mapped at those indices.
And then you won't need waste memory with these MAX_ORDER boundary
adjustments.
Really, I think IA64 should do this too (it's the only remaining
HOLES_IN_ZONE setting arch), then we can just delete this whole thing
completely.
next prev parent reply other threads:[~2009-02-05 23:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-05 6:26 HOLES_IN_ZONE David Miller
2009-02-05 7:43 ` HOLES_IN_ZONE KAMEZAWA Hiroyuki
2009-02-05 8:00 ` HOLES_IN_ZONE Heiko Carstens
2009-02-05 23:44 ` David Miller [this message]
2009-02-06 7:59 ` HOLES_IN_ZONE Heiko Carstens
2009-02-05 9:06 ` HOLES_IN_ZONE KAMEZAWA Hiroyuki
2009-02-05 9:21 ` HOLES_IN_ZONE David Miller
2009-02-05 9:34 ` HOLES_IN_ZONE KAMEZAWA Hiroyuki
2009-02-05 9:56 ` HOLES_IN_ZONE David Miller
2009-02-05 10:39 ` HOLES_IN_ZONE Mel Gorman
2009-02-05 11:14 ` [BUGFIX][PATCH] fix memmap init to initialize valid memmap for memory hole. (Was HOLES_IN_ZONE KAMEZAWA Hiroyuki
2009-02-05 10:10 ` HOLES_IN_ZONE Mel Gorman
2009-02-05 10:14 ` HOLES_IN_ZONE David Miller
2009-02-05 10:41 ` HOLES_IN_ZONE Mel Gorman
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=20090205.154403.200370311.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=akpm@linux-foundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=sparclinux@vger.kernel.org \
/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
Powered by JetHome