All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
To: linux-ia64@vger.kernel.org
Subject: Re: ia64 ORDERROUNDDOWN issue
Date: Thu, 30 Nov 2006 10:47:09 +0000	[thread overview]
Message-ID: <456EB6AD.6000406@bull.net> (raw)
In-Reply-To: <456D9FD2.2070906@bull.net>

>> Do we need a "max_order" variable that could be adjusted to some lower
>> value that MAX_ORDER if we find the memory topology doesn't fit inside
>> the lines?  
>
> (Your email talks about nodes, but I am asuming that we're actually dealing
> with per-zone concepts here)

...and ...

> But I wonder if a better approach would be to teach ia64 to just throw away
> the last 1 ..  MAX_ORDER-1 pages from the oddball zone?

Assume we've got a machine with a memory configuration:

Node 0:		0 ... 4 Gbyte - 1
Node 1:		4 Gbyte ... 16 Gbyte - 1

Assume MAX_ORDER is 8 Gbytes (a single binary, for all of our machines,
for maintenance reasons).

An allocation of 8 Gbytes should have its chance.
Therefore the global MAX_ORDER should not be diminished dynamically.
Surely we do not want to throw away 4 Gbytes of memory.

The kernel should support that both of the nodes have starting address at 0.
Therefore the "node_bootmem_map"-s of both of the nodes include the address
range 0 ... 4 Gbyte in the example above.
The "node_bootmem_map" of node 1 just happens to contain 0-s in the range
of 0 ... 4 Gbyte.

A not-in-use level of the buddy allocator
(the 8 Gbyte level on node 0 in the example above)
does not cost too much, I think there is no use to add complexity to the
allocator code.

Thanks,

Zoltan Menyhart

P.S. I guess it is not an ia64-only issue.

 

  reply	other threads:[~2006-11-30 10:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-29 14:57 ia64 ORDERROUNDDOWN issue xb
2006-11-30 10:47 ` Zoltan Menyhart [this message]
     [not found] <617E1C2C70743745A92448908E030B2AD89B2A@scsmsx411.amr.corp.intel.com>
2006-11-29 21:21 ` Andrew Morton
2006-11-29 21:21   ` Andrew Morton

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=456EB6AD.6000406@bull.net \
    --to=zoltan.menyhart@bull.net \
    --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.