From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFC] cgroup TODOs Date: Fri, 14 Sep 2012 11:33:16 -0700 Message-ID: <20120914183316.GG17747@google.com> References: <20120913205827.GO7677@google.com> <5052E7DF.7040000@parallels.com> <5052F4FF.6070508@huawei.com> <20120914175944.GF17747@google.com> <1347647021.7172.74.camel@twins> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=slrLtCkAFYXTG4FtMvvGn9FXzfqMC5lnpTRfVaAyaw0=; b=vflAGS9V1mRf8mIYvvQcrbC/Qjp5Hf0OfHiVizp78s0FFvdhvKCU9WMxJJuZmB+x2f MVOgK1Sv5YdtmR5tzqliZ/w/cGFYKCHvda2hJXlg4X6WbcACulAwlJCrDr6a3z0duFgL v80++9U2aqfWqE3Di6CrDY8Zd+3VDIP80yuME82ba324iCTJaeqNOfKWZ0lljTfErAd9 oxA24oO7KeZFh/Vzxck1daqL2I6ic3GCujN+Ad1Unsha2NdSXT+kLydjEzZsyGCeH+UE r14fS4tksaT2elyzkbRRwilnLAwmshHJfFS6Aw9tqmVcDjdIbl8vSqqihuwce5YpObX+ Rbkw== Content-Disposition: inline In-Reply-To: <1347647021.7172.74.camel@twins> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Peter Zijlstra Cc: Lennart Poettering , Neil Horman , "Serge E. Hallyn" , containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Kay Sievers , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Michal Hocko , Paul Mackerras , "Aneesh Kumar K.V" , Arnaldo Carvalho de Melo , Johannes Weiner , Thomas Graf , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Paul Turner , Ingo Molnar Hello, On Fri, Sep 14, 2012 at 08:23:41PM +0200, Peter Zijlstra wrote: > Its hotplug, all hotplug stuff is synchronous, the last thing hotplug > needs is the added complexity of async callbacks. Also pushing stuff out > into worklets just to work around locking issues is vile. I was asking whether it *has* to be part of synchronous CPU hotplug operation. IOW, do all tasks in the depleted cgroup have to be moved to its parent before CPU hotunplug can proceed to completion or is it okay to happen afterwards? Making the migration part asynchronous doesn't add much complexity. The only thing you have to make sure is flushing the previously scheduled one from the next CPU_UP_PREPARE. Also note that this can't easily be solved by splitting tree protecting inner lock from the outer lock. We're talking about doing full migration operations which likely require the outer one too. > > > Can't we play games by pinning both cgroups with a reference and playing > games with threadgroup_change / task_lock for the individual tasks being > moved about? I'm lost. Can you please elaborate? Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759834Ab2INSdX (ORCPT ); Fri, 14 Sep 2012 14:33:23 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:40510 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759317Ab2INSdV (ORCPT ); Fri, 14 Sep 2012 14:33:21 -0400 Date: Fri, 14 Sep 2012 11:33:16 -0700 From: Tejun Heo To: Peter Zijlstra Cc: Li Zefan , Glauber Costa , containers@lists.linux-foundation.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Michal Hocko , Paul Turner , Johannes Weiner , Thomas Graf , "Serge E. Hallyn" , Paul Mackerras , Ingo Molnar , Arnaldo Carvalho de Melo , Neil Horman , "Aneesh Kumar K.V" , "Daniel P. Berrange" , Lennart Poettering , Kay Sievers Subject: Re: [RFC] cgroup TODOs Message-ID: <20120914183316.GG17747@google.com> References: <20120913205827.GO7677@google.com> <5052E7DF.7040000@parallels.com> <5052F4FF.6070508@huawei.com> <20120914175944.GF17747@google.com> <1347647021.7172.74.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1347647021.7172.74.camel@twins> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Fri, Sep 14, 2012 at 08:23:41PM +0200, Peter Zijlstra wrote: > Its hotplug, all hotplug stuff is synchronous, the last thing hotplug > needs is the added complexity of async callbacks. Also pushing stuff out > into worklets just to work around locking issues is vile. I was asking whether it *has* to be part of synchronous CPU hotplug operation. IOW, do all tasks in the depleted cgroup have to be moved to its parent before CPU hotunplug can proceed to completion or is it okay to happen afterwards? Making the migration part asynchronous doesn't add much complexity. The only thing you have to make sure is flushing the previously scheduled one from the next CPU_UP_PREPARE. Also note that this can't easily be solved by splitting tree protecting inner lock from the outer lock. We're talking about doing full migration operations which likely require the outer one too. > > > Can't we play games by pinning both cgroups with a reference and playing > games with threadgroup_change / task_lock for the individual tasks being > moved about? I'm lost. Can you please elaborate? Thanks. -- tejun