Re: [PATCH 1/2] mm/migrate: optimize hotplug-time demotion order updates

[Huang, Ying]

Dave Hansen <dave.hansen@xxxxxxxxx> writes:

> On 9/21/21 7:36 AM, Huang, Ying wrote:
>>> This removes the need for the demotion code to track *any* state.  I've
>>> attached a totally untested patch to do this.
>> Yes.  This sounds good.  I will try to test this patch on my side.
>> 
>>>From another point of view, we still need to update demotion order upon
>> CPU hotplug too, because whether a node has CPU may be changed there.
>> And we need a solution for that too.
>
> Just to recap...  The reason I sent this series is that there's a known,
> detectable regression in a memory hotplug "benchmark".  This affects the
> 5.15 series.
>
> While I agree that we should look into the impact on CPU hotplug, I
> think we should probably focus on the *known* memory hotplug issue for 5.15.

Yes.  We got a regression report about memory hotplug.  And that
reminded me that CPU hotplug may be a problem too.  Because CPU hotplug
is used during suspend/resume for every laptop.  The latency of
suspend/resume may impact the user experience of the Linux laptop users.

And, it seems that your previous solution can deal with CPU hotplug
too.   So, can we keep that too for CPU hotplug?

Best Regards,
Huang, Ying