adding RobH (sorry, accidentally dropped Rob id in previous email) On Thu, Feb 11, 2016 at 6:33 PM, Ganapatrao Kulkarni <gpkulkarni@xxxxxxxxx> wrote: > Hi Ard, > > On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel > <ard.biesheuvel@xxxxxxxxxx> wrote: >> On 11 February 2016 at 12:42, Robert Richter >> <robert.richter@xxxxxxxxxxxxxxxxxx> wrote: >>> (+RobH and MarkR) >>> >>> On 09.02.16 15:35:42, Ard Biesheuvel wrote: >>>> (+ Grant) >>>> >>>> On 9 February 2016 at 14:53, Robert Richter <rrichter@xxxxxxxxxxxxxxxxxx> wrote: >>>> > From: Robert Richter <rrichter@xxxxxxxxxx> >>>> > >>>> > 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@xxxxxxxxxx >>>> > >>>> > 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@xxxxxxxxxxxxxxxxxx >>>> > >>>> >>>> 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. >> >> 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@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > thanks > Ganapat Ganapat -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
