Hello: On 06/14/2017 12:27 AM, Balbir Singh wrote: > On Wed, Jun 14, 2017 at 3:25 PM, Balbir Singh <bsinghar...@gmail.com> wrote: >> >> >> On Wed, Jun 14, 2017 at 8:21 AM, Michael Bringmann <m...@linux.vnet.ibm.com> >> wrote: >>> >>> On a related note, we are discussing the addition of 2 new device-tree >>> properties >>> with Pete Heyrman and his fellows that should simplify the determination >>> of the >>> set of required nodes. >>> >>> * One property would provide the total/max number of nodes needed by the >>> kernel >>> on the current hardware. >> >> > > Yes, that would be nice to have > >> >>> >>> * A second property would provide the total/max number of nodes that the >>> kernel >>> could use on any system to which it could be migrated. >>> >> > > Not sure about this one, are you suggesting more memory can be added > depending on the migration target?
We would use only one of these numbers to allocate nodes. I have only been on the periphery of the discussions, so I can not communicate the full reasoning as to why both measures would be needed. We would like to have the first number for node allocation/initialization, but if only the second value were provided, we would likely need to use it. >> >> >>> >>> These properties aren't available, yet, and it takes time to define new >>> properties >>> in the PAPR and have them implemented in pHyp and the kernel. As an >>> intermediary >>> step, the systems which are doing a lot of dynamic hot-add/hot-remove >>> configuration >>> could provide equivalent information to the PowerPC kernel with a command >>> line >>> parameter. The 'numa.c' code would then read this value and fill in the >>> necessary >>> entries in the 'node_possible_map'. >>> >>> Would you foresee any problems with using such a feature? >> >> > > Sorry my mailer goofed up, resending > > Balbir Singh > Thanks. -- Michael W. Bringmann Linux Technology Center IBM Corporation Tie-Line 363-5196 External: (512) 286-5196 Cell: (512) 466-0650 m...@linux.vnet.ibm.com