public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"Frank Rowand" <frowand.list@gmail.com>,
	devicetree <devicetree@vger.kernel.org>,
	Zefan Li <lizefan@huawei.com>, Xinwei Hu <huxinwei@huawei.com>,
	Tianhong Ding <dingtianhong@huawei.com>,
	Hanjun Guo <guohanjun@huawei.com>
Subject: Re: [PATCH v7 09/14] arm64/numa: support HAVE_SETUP_PER_CPU_AREA
Date: Sat, 27 Aug 2016 18:06:09 +0800	[thread overview]
Message-ID: <57C16611.1040206@huawei.com> (raw)
In-Reply-To: <20160826132838.GE30302@arm.com>



On 2016/8/26 21:28, Will Deacon wrote:
> On Wed, Aug 24, 2016 at 03:44:48PM +0800, Zhen Lei wrote:
>> To make each percpu area allocated from its local numa node. Without this
>> patch, all percpu areas will be allocated from the node which cpu0 belongs
>> to.
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>>  arch/arm64/Kconfig   |  8 ++++++++
>>  arch/arm64/mm/numa.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 63 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index bc3f00f..2815af6 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -603,6 +603,14 @@ config USE_PERCPU_NUMA_NODE_ID
>>  	def_bool y
>>  	depends on NUMA
>>
>> +config HAVE_SETUP_PER_CPU_AREA
>> +	def_bool y
>> +	depends on NUMA
>> +
>> +config NEED_PER_CPU_EMBED_FIRST_CHUNK
>> +	def_bool y
>> +	depends on NUMA
> 
> Why do we need this? Is it purely about using block mappings for the
> pcpu area?
Without NEED_PER_CPU_EMBED_FIRST_CHUNK, Link error will be reported.

#if defined(CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK) || \
	!defined(CONFIG_HAVE_SETUP_PER_CPU_AREA)
#define BUILD_EMBED_FIRST_CHUNK
#endif

#if defined(BUILD_EMBED_FIRST_CHUNK)
//pcpu_embed_first_chunk definition
#endif

setup_per_cpu_areas -->pcpu_embed_first_chunk


> 
>>  source kernel/Kconfig.preempt
>>  source kernel/Kconfig.hz
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 7b73808..5e44ad1 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -26,6 +26,7 @@
>>  #include <linux/of.h>
>>
>>  #include <asm/acpi.h>
>> +#include <asm/sections.h>
>>
>>  struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
>>  EXPORT_SYMBOL(node_data);
>> @@ -131,6 +132,60 @@ void __init early_map_cpu_to_node(unsigned int cpu, int nid)
>>  	cpu_to_node_map[cpu] = nid;
>>  }
>>
>> +#ifdef CONFIG_HAVE_SETUP_PER_CPU_AREA
>> +unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
>> +EXPORT_SYMBOL(__per_cpu_offset);
>> +
>> +static int __init early_cpu_to_node(int cpu)
>> +{
>> +	return cpu_to_node_map[cpu];
>> +}
>> +
>> +static int __init pcpu_cpu_distance(unsigned int from, unsigned int to)
>> +{
>> +	if (early_cpu_to_node(from) == early_cpu_to_node(to))
>> +		return LOCAL_DISTANCE;
>> +	else
>> +		return REMOTE_DISTANCE;
>> +}
> 
> Is it too early to use __node_distance here?
Good, we can directly use node_distance, thanks.

> 
>> +static void * __init pcpu_fc_alloc(unsigned int cpu, size_t size,
>> +				       size_t align)
>> +{
>> +	int nid = early_cpu_to_node(cpu);
>> +
>> +	return  memblock_virt_alloc_try_nid(size, align,
>> +			__pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, nid);
>> +}
>> +
>> +static void __init pcpu_fc_free(void *ptr, size_t size)
>> +{
>> +	memblock_free_early(__pa(ptr), size);
>> +}
>> +
>> +void __init setup_per_cpu_areas(void)
>> +{
>> +	unsigned long delta;
>> +	unsigned int cpu;
>> +	int rc;
>> +
>> +	/*
>> +	 * Always reserve area for module percpu variables.  That's
>> +	 * what the legacy allocator did.
>> +	 */
>> +	rc = pcpu_embed_first_chunk(PERCPU_MODULE_RESERVE,
>> +				    PERCPU_DYNAMIC_RESERVE, PAGE_SIZE,
>> +				    pcpu_cpu_distance,
>> +				    pcpu_fc_alloc, pcpu_fc_free);
>> +	if (rc < 0)
>> +		panic("Failed to initialize percpu areas.");
>> +
>> +	delta = (unsigned long)pcpu_base_addr - (unsigned long)__per_cpu_start;
>> +	for_each_possible_cpu(cpu)
>> +		__per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
>> +}
>> +#endif
> 
> It's a pity that this is practically identical to PowerPC. Ideally, there
> would be definitions of this initialisation gunk in the core code that
> could be reused across architectures.
But these are different from other ARCHs, except PPC.

I originally want to put it into driver/of/of_numa.c, but now the ACPI NUMA is
coming up, so I don't known where.

> 
> Will
> 
> .
> 

  reply	other threads:[~2016-08-27 10:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-24  7:44 [PATCH v7 00/14] fix some type infos and bugs for arm64/of numa Zhen Lei
2016-08-24  7:44 ` [PATCH v7 01/14] of/numa: remove a duplicated pr_debug information Zhen Lei
2016-08-24  7:44 ` [PATCH v7 02/14] of/numa: fix a memory@ node can only contains one memory block Zhen Lei
2016-08-24  7:44 ` [PATCH v7 03/14] arm64/numa: add nid check for " Zhen Lei
2016-08-26 12:39   ` Will Deacon
2016-08-27  8:02     ` Leizhen (ThunderTown)
2016-08-24  7:44 ` [PATCH v7 04/14] of/numa: remove a duplicated warning Zhen Lei
2016-08-24  7:44 ` [PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed Zhen Lei
2016-08-26 12:47   ` Will Deacon
2016-08-27  8:54     ` Leizhen (ThunderTown)
2016-08-30 17:51       ` Will Deacon
2016-08-31  2:29         ` Leizhen (ThunderTown)
2016-08-24  7:44 ` [PATCH v7 06/14] of_numa: Use of_get_next_parent to simplify code Zhen Lei
2016-08-24  7:44 ` [PATCH v7 07/14] of_numa: Use pr_fmt() Zhen Lei
2016-08-24  7:44 ` [PATCH v7 08/14] arm64: numa: " Zhen Lei
2016-08-26 12:54   ` Will Deacon
2016-08-27  9:14     ` Leizhen (ThunderTown)
2016-08-24  7:44 ` [PATCH v7 09/14] arm64/numa: support HAVE_SETUP_PER_CPU_AREA Zhen Lei
2016-08-26 13:28   ` Will Deacon
2016-08-27 10:06     ` Leizhen (ThunderTown) [this message]
2016-08-24  7:44 ` [PATCH v7 10/14] arm64/numa: define numa_distance as array to simplify code Zhen Lei
2016-08-26 15:29   ` Will Deacon
2016-08-27 10:29     ` Leizhen (ThunderTown)
2016-08-24  7:44 ` [PATCH v7 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES Zhen Lei
2016-08-26 15:43   ` Will Deacon
2016-08-27 11:05     ` Leizhen (ThunderTown)
2016-08-29  3:15       ` Leizhen (ThunderTown)
2016-08-24  7:44 ` [PATCH v7 12/14] arm64/numa: remove the limitation that cpu0 must bind to node0 Zhen Lei
2016-08-26 15:49   ` Will Deacon
2016-08-29  6:55     ` Leizhen (ThunderTown)
2016-08-24  7:44 ` [PATCH v7 13/14] of/numa: remove the constraint on the distances of node pairs Zhen Lei
2016-08-24  7:44 ` [PATCH v7 14/14] Documentation: " Zhen Lei
2016-08-26 15:35   ` Will Deacon
2016-08-27 10:44     ` Leizhen (ThunderTown)
2016-08-30 17:55       ` Will Deacon
2016-08-31  2:46         ` Leizhen (ThunderTown)

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=57C16611.1040206@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dingtianhong@huawei.com \
    --cc=frowand.list@gmail.com \
    --cc=guohanjun@huawei.com \
    --cc=huxinwei@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=robh+dt@kernel.org \
    --cc=will.deacon@arm.com \
    /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