[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d87ef236-f113-8765-7fef-e41db0adf2b2@intel.com>
Date: Tue, 21 Sep 2021 10:01:35 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Huang, Ying" <ying.huang@...el.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
linux-kernel@...r.kernel.org, oliver.sang@...el.com,
mhocko@...e.com, weixugc@...gle.com, osalvador@...e.de,
rientjes@...gle.com, dan.j.williams@...el.com, david@...hat.com,
gthelen@...gle.com, yang.shi@...ux.alibaba.com,
akpm@...ux-foundation.org
Subject: Re: [PATCH 1/2] mm/migrate: optimize hotplug-time demotion order
updates
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.
Powered by blists - more mailing lists