[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171213160617.GQ3919388@devbig577.frc2.facebook.com>
Date: Wed, 13 Dec 2017 08:06:17 -0800
From: Tejun Heo <tj@...nel.org>
To: Prateek Sood <prsood@...eaurora.org>
Cc: Peter Zijlstra <peterz@...radead.org>, 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
Hello, Prateek.
On Wed, Dec 13, 2017 at 01:20:46PM +0530, Prateek Sood wrote:
> This change makes the usage of cpuset_hotplug_workfn() from cpu
> hotplug path synchronous. For memory hotplug it still remains
> asynchronous.
Ah, right.
> 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.
No, I didn't. I was just confused about which part became
synchronous. So, I don't have anything against making the cpu part
synchronous, but let's not do that as the fix to the deadlocks cuz,
while we can avoid them by changing cpuset, I don't think cpuset is
the root cause for them. If there are benefits to making cpuset cpu
migration synchronous, let's do that for those benefits.
Thanks.
--
tejun
Powered by blists - more mailing lists