[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cca9aea2-9bff-decf-d669-8f90b928ea18@codeaurora.org>
Date: Wed, 13 Dec 2017 13:20:46 +0530
From: Prateek Sood <prsood@...eaurora.org>
To: Tejun Heo <tj@...nel.org>, Peter Zijlstra <peterz@...radead.org>
Cc: avagin@...il.com, mingo@...nel.org, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, sramana@...eaurora.org
Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency
On 12/11/2017 08:50 PM, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, Dec 05, 2017 at 12:01:17AM +0100, Peter Zijlstra wrote:
>>> AFAICS, this should remove the circular dependency you originally
>>> reported. I'll revert the two cpuset commits for now.
>>
>> So I liked his patches in that we would be able to go back to
>> synchronous sched_domain building.
>
> Ah, yeah, that's a separate issue but didn't we intentionally make
> that asynchronous? IIRC, cpuset migration can take a really long time
> when the memory migration is turned on and doing that synchronously
> could mess up the system.
>
> Thanks.
>
Hi TJ,
This change makes the usage of cpuset_hotplug_workfn() from cpu
hotplug path synchronous. For memory hotplug it still remains
asynchronous.
Memory migration happening from cpuset_hotplug_workfn() is
already asynchronous by queuing cpuset_migrate_mm_workfn() in
cpuset_migrate_mm_wq.
cpuset_hotplug_workfn()
cpuset_hotplug_workfn(()
cpuset_migrate_mm()
queue_work(cpuset_migrate_mm_wq)
It seems that memory migration latency might not have
impact with this change.
Please let me know if you meant something else by cpuset
migration taking time when memory migration is turned on.
Thanks
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
Powered by blists - more mailing lists