<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 20, 2017 at 6:51 PM, Nathan Fontenot <span dir="ltr"><<a href="mailto:nfont@linux.vnet.ibm.com" target="_blank">nfont@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This patch set provides a set of updates to de-couple the LMB information<br>
provided in the ibm,dynamic-memory device tree property from the device<br>
tree property format. A part of this patch series introduces a new<br>
device tree property format for dynamic memory, ibm-dynamic-meory-v2.<br>
By separating the device tree format from the information provided by<br>
the device tree property consumers of this information need not know<br>
what format is currently being used and provide multiple parsing routines<br>
for the information.<br>
<br>
The first two patches update the of_get_assoc_arrays() and<br>
of_get_usable_memory() routines to look up the device node for the<br>
properties they parse. This is needed because the calling routines for<br>
these two functions will not have the device node to pass in in<br>
subsequent patches.<br>
<br>
The third patch adds a new kernel structure, struct drmem_lmb, that<br>
is used to represent each of the possible LMBs specified in the<br>
ibm,dynamic-memory* device tree properties. The patch adds code<br>
to parse the property and build the LMB array data, and updates prom.c<br>
to use this new data structure instead of parsing the device tree directly.<br>
<br>
The fourth and fifth patches update the numa and pseries hotplug code<br>
respectively to use the new LMB array data instead of parsing the<br>
device tree directly.<br>
<br>
The sixth patch moves the of_drconf_cell struct to drmem.h where it<br>
fits better than prom.h<br>
<br>
The seventh patch introduces support for the ibm,dynamic-memory-v2<br>
property format by updating the new drmem.c code to be able to parse<br>
and create this new device tree format.<br>
<br>
The last patch in the series updates the architecture vector to indicate<br>
support for ibm,dynamic-memory-v2.</blockquote></div><br></div><div class="gmail_extra">Here we are consolidating LMBs into LMB sets but still end up working with individual LMBs during hotplug. Can we instead start working with LMB sets together during hotplug ? In other words<br><br></div><div class="gmail_extra">- The RTAS calls involved during DRC acquire stage can be done only once per LMB set.<br></div><div class="gmail_extra">- One configure-connector call for the entire LMB set.<br><br></div><div class="gmail_extra">I think this should help hotplugging of large amounts of memory. Other than that, if we choose to use LMB representation for PMEM, it will be useful there too to handle all the LMBs of a PMEM range as one set.<br><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Bharata.<br></div></div>