[lkml]   [2017]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] cgroup/cpuset: fix circular locking dependency
On 12/13/2017 09:36 PM, Tejun Heo wrote:
> 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.

Making CPU part synchronous can only be achieved if we retain the
patch for inverting the locking order for cpuset_mutex and

> Thanks.


Do you suggest taking both the patches:
1) Inverting locking order of cpuset_mutex and cpu_hotplug_lock.
2) Make cpuset hotplug work synchronous.


I would leave it for you and TJ to decide on this.


Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project

 \ /
  Last update: 2017-12-15 20:05    [W:0.089 / U:0.496 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site