On Fri, Aug 9, 2013 at 4:56 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 08/09/2013 04:53 PM, Yinghai Lu wrote: >> On Fri, Aug 9, 2013 at 4:43 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >>> On 08/09/2013 04:39 PM, Yinghai Lu wrote: >>>>>> >>>>>> Also parse srat table two times looks silly. >>>>> >>>>> By parsing SRAT twice, I can avoid memory allocation for acpi_tables_addr >>>>> in acpi_initrd_override_copy() procedure at such an early time. This memory >>>>> could also be in hotpluggable area. >>>> >>>> You already mark kernel position to be not hot-plugged, so near the >>>> kernel range should be safe to be put override acpi tables. >>>> >>>> also what I mean parse srat two times: >>>> parse to get hotplug range, and late parse other numa info again. >>>> >>> >>> Doing two passes over a small data structure (SRAT) would seem more >>> sensible than allocating memory just to avoid that... >> >> for x86 there is some numa info discovery path, and there are chance >> srat is wrong but still have hotplug range there, or numa finally is using other >> way or not used. Inconsistency looks weird. >> >> numa_meminfo is static struct, we have way to get final numa info early enough >> before we need use memblock to alloc buffer with it. >> > > Now, for kernel-generated data if you can define a sensible maximum you > can put it in brk, if not, you have a serious problem. Yes, that could be even better, we just can numa_info parsing early but just make them to use brk if it need extra buffer. In the way we may not need to split things to two steps or two pass etc. Yinghai -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>