[PATCHv3 2/2] powerpc/pseries: update device tree before ejecting hotplug uevents
Nathan Lynch
nathanl at linux.ibm.com
Fri Jul 24 12:50:12 EDT 2020
Pingfan Liu <kernelfans at gmail.com> writes:
> On Thu, Jul 23, 2020 at 9:27 PM Nathan Lynch <nathanl at linux.ibm.com> wrote:
>> Pingfan Liu <kernelfans at gmail.com> writes:
>> > This will introduce extra dt updating payload for each involved lmb when hotplug.
>> > But it should be fine since drmem_update_dt() is memory based operation and
>> > hotplug is not a hot path.
>>
>> This is great analysis but the performance implications of the change
>> are grave. The add/remove paths here are already O(n) where n is the
>> quantity of memory assigned to the LP, this change would make it O(n^2):
>>
>> dlpar_memory_add_by_count
>> for_each_drmem_lmb <--
>> dlpar_add_lmb
>> drmem_update_dt(_v1|_v2)
>> for_each_drmem_lmb <--
>>
>> Memory add/remove isn't a hot path but quadratic runtime complexity
>> isn't acceptable. Its current performance is bad enough that I have
> Yes, the quadratic runtime complexity sounds terrible.
> And I am curious about the bug. Does the system have thousands of lmb?
Yes.
>> Not to mention we leak memory every time drmem_update_dt is called
>> because we can't safely free device tree properties :-(
> Do you know what block us to free it?
It's a longstanding problem. References to device tree properties aren't
counted or tracked so there's no way to safely free them unless the node
itself is released. But the ibm,dynamic-reconfiguration-memory node does
not ever go away and its properties are only subject to updates.
Maybe there's a way to address the specific case of
ibm,dynamic-reconfiguration-memory and the ibm,dynamic-memory(-v2)
properties, instead of tackling the general problem.
Regardless of all that, the drmem code needs better data structures and
lookup functions.
More information about the kexec
mailing list