This patchset intends to reduce time needed for processing memory hotplug/hotunplug in hash guests.
The first one, makes sure guests with pagesize over 4k don't need to go through HPT resize-downs after memory hotplug. The second and third patches make hotplug / hotunplug perform a single HPT resize per operation, instead of one for each shift change, or one for each LMB in case of resize-down error. Why haven't the same mechanism used for both memory hotplug and hotunplug? They both have different requirements: Memory hotplug causes (usually) HPT resize-ups, which are fine happening at the start of hotplug, but resize-ups should not ever be disabled, as other mechanisms may try to increase memory, hitting issues with a HPT that is too small. Memory hotunplug causes HPT resize-downs, which can be disabled (HPT will just remain larger for a while), but need to happen at the end of an hotunplug operation. If we want to batch it, we need to disable resize-downs and perform it only at the end. Tests done with this patchset in the same machine / guest config: Starting memory: 129GB, DIMM: 256GB Before patchset: hotplug = 710s, hotunplug = 621s. After patchset: hotplug = 21s, hotunplug = 100s. Any feedback will be appreciated! Changes since v1: - Atomic used to disable resize was replaced by a mutex - Removed wrappers, testing for !radix directly in hot(un)plug routine - Added bounds to HPT resize loop - Removed batching from dlpar_memory_*_by_index, as it adds a single LMB Best regards, Leonardo Bras (3): powerpc/mm/hash: Avoid resizing-down HPT on first memory hotplug powerpc/mm/hash: Avoid multiple HPT resize-ups on memory hotplug powerpc/mm/hash: Avoid multiple HPT resize-downs on memory hotunplug arch/powerpc/include/asm/book3s/64/hash.h | 4 + arch/powerpc/mm/book3s64/hash_utils.c | 95 ++++++++++++++++--- .../platforms/pseries/hotplug-memory.c | 35 +++++++ 3 files changed, 119 insertions(+), 15 deletions(-) -- 2.30.2