All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: jschopp@austin.ibm.com
Cc: linuxppc64-dev@ozlabs.org, paulus@samba.org, anton@samba.org,
	linux-mm@kvack.org, haveblue@us.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [1/3] add early_pfn_to_nid for ppc64
Date: Thu, 05 May 2005 17:19:19 +0100	[thread overview]
Message-ID: <427A4787.4030802@shadowen.org> (raw)
In-Reply-To: <427A3F6A.6060405@austin.ibm.com>

Joel Schopp wrote:
>> +#ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
>> +#define early_pfn_to_nid(pfn)  pa_to_nid(((unsigned long)pfn) <<
>> PAGE_SHIFT)
>> +#endif
> 
> 
> Is there a reason we didn't just use pfn_to_nid() directly here instead
> of pa_to_nid()?  I'm just thinking of having DISCONTIG/NUMA off and
> pfn_to_nid() being #defined to zero for those cases.

The problem is that pfn_to_nid is defined by the memory model.  In the
SPARSEMEM case it isn't always usable until after the we have
initialised and allocated the sparse mem_maps.  It is allocations during
this phase that need this early_pfn_to_nid() form, to guide its
allocations of the mem_map to obtain locality with the physical memory
blocks.

This is clearer in the i386 port where the early_pfn_to_nid()
implementation uses low level table to determine the location.  As has
been mentioned in another thread, we are using what is effectivly a
DISCONTIGMEM data structure here.  I have some work in progress to split
that last part and move to a true early implementation on ppc64 too.

-apw

WARNING: multiple messages have this Message-ID (diff)
From: Andy Whitcroft <apw@shadowen.org>
To: jschopp@austin.ibm.com
Cc: linuxppc64-dev@ozlabs.org, paulus@samba.org, anton@samba.org,
	linux-mm@kvack.org, haveblue@us.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [1/3] add early_pfn_to_nid for ppc64
Date: Thu, 05 May 2005 17:19:19 +0100	[thread overview]
Message-ID: <427A4787.4030802@shadowen.org> (raw)
In-Reply-To: <427A3F6A.6060405@austin.ibm.com>

Joel Schopp wrote:
>> +#ifdef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
>> +#define early_pfn_to_nid(pfn)  pa_to_nid(((unsigned long)pfn) <<
>> PAGE_SHIFT)
>> +#endif
> 
> 
> Is there a reason we didn't just use pfn_to_nid() directly here instead
> of pa_to_nid()?  I'm just thinking of having DISCONTIG/NUMA off and
> pfn_to_nid() being #defined to zero for those cases.

The problem is that pfn_to_nid is defined by the memory model.  In the
SPARSEMEM case it isn't always usable until after the we have
initialised and allocated the sparse mem_maps.  It is allocations during
this phase that need this early_pfn_to_nid() form, to guide its
allocations of the mem_map to obtain locality with the physical memory
blocks.

This is clearer in the i386 port where the early_pfn_to_nid()
implementation uses low level table to determine the location.  As has
been mentioned in another thread, we are using what is effectivly a
DISCONTIGMEM data structure here.  I have some work in progress to split
that last part and move to a true early implementation on ppc64 too.

-apw
--
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:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2005-05-05 16:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-04 20:28 [1/3] add early_pfn_to_nid for ppc64 Andy Whitcroft
2005-05-04 20:28 ` Andy Whitcroft
2005-05-05 15:44 ` Joel Schopp
2005-05-05 15:44   ` Joel Schopp
2005-05-05 16:19   ` Andy Whitcroft [this message]
2005-05-05 16:19     ` Andy Whitcroft

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=427A4787.4030802@shadowen.org \
    --to=apw@shadowen.org \
    --cc=anton@samba.org \
    --cc=haveblue@us.ibm.com \
    --cc=jschopp@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=paulus@samba.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.