All of lore.kernel.org
 help / color / mirror / Atom feed
From: jbarnes@sgi.com (Jesse Barnes)
To: linux-ia64@vger.kernel.org
Subject: Re: discontig patch question
Date: Mon, 10 Nov 2003 17:23:05 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106848499725954@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106847971018555@msgid-missing>

On Mon, Nov 10, 2003 at 09:52:49AM -0600, Van Maren, Kevin wrote:
> The EFI memory map is simple, and looks like:
>  0- 4G Node 0 (2G + 2G hole)
>  4- 8G Node 1
>  8-12G Node 2
> 12-16G Node 3
> 16-20G Node 0 (2 G memory-map I/O reclaim)
> with 4G per node, 16GB total.
> 
> Because of ORDERROUNDDOWN in count_pages (arch/ia64/mm/init.c),
> the memory ended up being assigned like this:
> 
>  0- 8G Node 1 (6G, 2GB hole)
>  8-16G Node 3 (8G)
> 16-20G Node 0 (2G)
>        Node 2 (0G)
> 
> Which was not at all what I wanted.

I guess I didn't see this because the nodes on sn2 are so large (64GB).

> ORDERROUNDDOWN causes the kernel to assign all memory starting at the
> (PAGE_SIZE << MAX_ORDER) boundary to the current node, which in my case
> is 16KB << 19 (hard-coded for IA64), or 8GB.

I wonder if that shouldn't be simply 1UL<<MAX_ORDER...  That's all that
mm/page_alloc.c seems to care about.

> I understand the GRANULE rounding, but is there a compelling reason that
> we need 8GB node chunks on IA64 Linux (with 16KB pages)?

I don't think so.

Jesse

  reply	other threads:[~2003-11-10 17:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-10 15:52 discontig patch question Van Maren, Kevin
2003-11-10 17:23 ` Jesse Barnes [this message]
2003-11-10 17:38 ` Van Maren, Kevin
2003-11-10 17:56 ` Jesse Barnes
2003-11-10 18:02 ` Seth, Rohit
2003-11-10 18:34 ` Van Maren, Kevin
2003-11-10 19:08 ` Jesse Barnes
2003-11-10 19:10 ` Jesse Barnes
2003-11-10 20:20 ` Seth, Rohit
2003-11-12 18:14 ` Van Maren, Kevin

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=marc-linux-ia64-106848499725954@msgid-missing \
    --to=jbarnes@sgi.com \
    --cc=linux-ia64@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 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.