[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH v3 07/24] ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA

Hi Vijay,

On 20/07/17 10:31, Vijay Kilari wrote:
On Tue, Jul 18, 2017 at 11:36 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
Hi Vijay,

On 18/07/17 12:41, vijay.kilari@xxxxxxxxx wrote:

From: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxx>

Right now CONFIG_NUMA is not enabled for ARM and
existing code in asm-arm/numa.h is for !CONFIG_NUMA.
Hence put this code under #ifndef CONFIG_NUMA.

This help to make this changes work when CONFIG_NUMA
is not enabled. Though CONFIG_NUMA is enabled by default,
manually disabling this option is possible and compilation
should go through. Hence kept the these changes under

This is still no true. It is not possible to disable CONFIG_NUMA from the
Kconfig unless you hack it (just tried it)...

As I said on v2, if you always enable NUMA why should we add code in Xen
that get rotten? Either you allow NUMA to be disabled by the user or you
drop this code.

The reason is: The next patch #8, which does the code movement moves
the generic code to common header file xen/numa.h.
If we don't put these *existing* defines in asm-arm/numa.h under
#ifndef CONFIG_NUMA,
the compilation fails for ARM.

Is it ok to removes these defines under separate patch after enabling
NUMA config
at the end of patch series?

Let me know if you have any better approach.

The question here is more, do we want to allow the user disabling NUMA (even if it has to be guarded with EXPERT)? You seem to choose the approach where NUMA is here by default and can't be disabled.

1) If we decide to let the user configuring NUMA, then this patch is valid as it is.

2) If not, then you need a patch drop this code at the end and have a word in this commit message explaining this is temporary...

When the question above is answered, you need to do either 1) or 2) according to the answer.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.