linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: xb <xavier.bru@bull.net>, linux-ia64@vger.kernel.org, linux-mm@kvack.org
Subject: Re: ia64 ORDERROUNDDOWN issue
Date: Wed, 29 Nov 2006 13:21:55 -0800	[thread overview]
Message-ID: <20061129132155.f617dcfb.akpm@osdl.org> (raw)
In-Reply-To: <617E1C2C70743745A92448908E030B2AD89B2A@scsmsx411.amr.corp.intel.com>

(add linux-mm)

On Wed, 29 Nov 2006 10:34:24 -0800
"Luck, Tony" <tony.luck@intel.com> wrote:

> > After some investigations I stated that count_node_pages() was computing 
> > mem_data[1].min_pfn = 0, and mem_data[1].max_pfn = 20000 for node 1, 
> > thus conflicting with the 0-2GB DMA memory range on node 0.
> > This is due to the line:
> >    start = ORDERROUNDDOWN(start);
> 
> There is an assumption here that the memory space on a node doesn't
> cross a MAX_ORDER boundary ... and I'm not really sure where to go
> with that.  Your patch papers over the problem for your specific case,
> but as you point out it will just re-appear for someone who picks
> a bigger MAX_ORDER.
> 
> Having nodes that are smaller than MAX_ORDER will cause confusion in
> the allocator (if all the memory belonging to two nodes is in a
> single MAX_ORDER page, the buddy allocator will give all the memory
> to one node, and none to the other (won't it?).
> 
> > This should at least be checked in the count_node_pages() function.
> 
> Yes, a check should be made ... but count_node_pages() doesn't have
> all the information if needs to do this (it just gets the start/size
> for the memory on the node ... and it needs to check whether the
> rounddown of the start address (or the roundup of the end address)
> would cause conflicts with memory belonging to other nodes.
> 
> 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)

We could of course do that, although it looks like your runtime max_order
should be per-zone and not global.  And making it a runtime thing would
cause more code to be emitted for alloc_pages() and alloc_pages_node(), so
we'd at least have to move their checks into .c.

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?


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

           reply	other threads:[~2006-11-29 21:21 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <617E1C2C70743745A92448908E030B2AD89B2A@scsmsx411.amr.corp.intel.com>]

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=20061129132155.f617dcfb.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tony.luck@intel.com \
    --cc=xavier.bru@bull.net \
    /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