[lkml]   [2016]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v4 0/6] arm64 UEFI early FDT handling
adding RobH
(sorry, accidentally dropped Rob id in previous email)

On Thu, Feb 11, 2016 at 6:33 PM, Ganapatrao Kulkarni
<> wrote:
> Hi Ard,
> On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
> <> wrote:
>> On 11 February 2016 at 12:42, Robert Richter
>> <> wrote:
>>> (+RobH and MarkR)
>>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>>> (+ Grant)
>>>> On 9 February 2016 at 14:53, Robert Richter <> wrote:
>>>> > From: Robert Richter <>
>>>> >
>>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>>> > a followup to the version 3 from:
>>>> >
>>>> >
>>>> >
>>>> > 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:
>>>> >
>>>> >
>>>> >
>>>> 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:
>>>> 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.
>> 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
> thanks
> Ganapat


 \ /
  Last update: 2016-02-11 15:41    [W:0.057 / U:2.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site