Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751173AbdLMHvB (ORCPT ); Wed, 13 Dec 2017 02:51:01 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:54166 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbdLMHu6 (ORCPT ); Wed, 13 Dec 2017 02:50:58 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 9CDE7604BE Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=prsood@codeaurora.org Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency To: Tejun Heo , Peter Zijlstra Cc: avagin@gmail.com, mingo@kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, sramana@codeaurora.org References: <1511868946-23959-1-git-send-email-prsood@codeaurora.org> <623f214b-8b9a-f967-7a3d-ca9c06151267@codeaurora.org> <20171204202219.GF2421075@devbig577.frc2.facebook.com> <20171204225825.GP2421075@devbig577.frc2.facebook.com> <20171204230117.GF20227@worktop.programming.kicks-ass.net> <20171211152059.GH2421075@devbig577.frc2.facebook.com> From: Prateek Sood Message-ID: Date: Wed, 13 Dec 2017 13:20:46 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20171211152059.GH2421075@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1398 Lines: 46 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