adding RobH
(sorry, accidentally dropped Rob id in previous email)

On Thu, Feb 11, 2016 at 6:33 PM, Ganapatrao Kulkarni
[off-list ref] wrote:

Hi Ard,

On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
[off-list ref] wrote:

quoted

On 11 February 2016 at 12:42, Robert Richter
[off-list ref] wrote:

quoted

(+RobH and MarkR)

On 09.02.16 15:35:42, Ard Biesheuvel wrote:

quoted

(+ Grant)

On 9 February 2016 at 14:53, Robert Richter [off-list ref] wrote:

quoted

From: Robert Richter <redacted>

Reposting an updated version of this patches ported to 4.5-rc1. It is
a followup to the version 3 from:

 http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org

The series is essential for NUMA on arm64. Early FDT handling is
required to make system topology data from firmware, esp. for cpus and
memory available to the early boot process. Ganapat's numa patches
depend on it. This series has been tested with his series v10 posted
here:

 http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com

Hello Robert,

This series does not reflect anymore what we think is the best way to
deal with memory nodes and memreserves on UEFI systems.
Please refer to this thread:
http://thread.gmane.org/gmane.linux.kernel.efi/6464

As far as the memory nodes are concerned, if it is the best place to
store these NUMA annotations, then we should indeed preserve them, but
I think the discussion stalled without any conclusion having been
reached. As far as the /reserved-memory node is concerned, that one we
should really keep, so at least patch 6/6 of this series should be
replaced with something based on the series above.

Ard,

Mark R and Rob have agreed for numa dt binding for mem nodes. So do
you think we can at least reuse parts of this series to solve the NUMA
issue and try to find a solution for patch #6 which aligns with your
alternative approach?

OK, if we are all in agreement that NUMA annotations belong in memory
nodes, which are otherwise ignored completely on UEFI systems, I am
fine with this as well.

However, we have to think about what it means if the memory nodes are
out of sync with the UEFI memory map, both on NUMA and ordinary
systems. I know very little about NUMA, but I could imagine that on
any UEFI system, the UEFI memory map remains authoritative, and memory
nodes are only used to annotate regions that are already known to
exist. Alternatively, some sanity check could be appropriate (such as
the one I proposed for the /reserved-memory node in the link above),
but we need to consider carefully how the firmware is supposed to
produce memory nodes and a UEFI memory map that are mutually
consistent.

Yes memory nodes are updated at runtime from the firmware/uefi with
actual size and
is aligned to efi memory table.
in NUMA patches it is taken care to fail, if memory table and memory
nodes(also ACPI SRAT table) are not aligned.

On thunderx, in uefi,  we do update memory nodes based on actual
memory present on each
nodes, which is not fixed on every board and varies based on number of
DIMMs etc present on board.

Same is done for ACPI SRAT table which is updated at runtime from uefi
with actual memory size of each node.

it is reasonable expectation from firmware to create/update dt or acpi
tables at runtime for a server platform.

for non-NUMA systems, dummy single node(node 0) numa system is created
using all available memory on system.
if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.

quoted

I think we can replace 6/6 with the series above, i.e., honour the
allocations after establishing that the fixed allocations are either
still available, or entirely disjoint from what the UEFI memory map
describes.

--
Ard.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

thanks
Ganapat

Ganapat