Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751723AbbEDEkJ (ORCPT ); Mon, 4 May 2015 00:40:09 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:31358 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbbEDEkF (ORCPT ); Mon, 4 May 2015 00:40:05 -0400 Message-ID: <5546F80B.3070802@huawei.com> Date: Mon, 4 May 2015 12:39:39 +0800 From: Zefan Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mike Galbraith CC: Ingo Molnar , Peter Zijlstra , Tejun Heo , LKML , Cgroups Subject: Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach() References: <5546C34C.7050202@huawei.com> <1430709236.3129.42.camel@gmail.com> In-Reply-To: <1430709236.3129.42.camel@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.18.230] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1567 Lines: 38 On 2015/5/4 11:13, Mike Galbraith wrote: > On Mon, 2015-05-04 at 08:54 +0800, Zefan Li wrote: >> It's allowed to promote a task from normal to realtime after it has been >> attached to a non-root cgroup, but it will fail if the attaching happens >> after it has become realtime. I don't see how this restriction is useful. > > In the CONFIG_RT_GROUP_SCHED case, promotion will fail is there is no > bandwidth allocated. > Right. I forgot to mention this patch affects !CONFIG_RT_GROUP_SCHED only, though it should be obvious by reading the change. >> We are moving toward unified hierarchy where all the cgroup controllers >> are bound together, so it would make cgroups easier to use if we have less >> restrictions on attaching tasks between cgroups. > > Forcing group scheduling overhead on users if they want cpuset or memory > cgroup functionality would be far from wonderful. Am I interpreting the > implications of this unification/binding properly? > > (I hope not, surely the plan is not to utterly _destroy_ cgroup utility) > Some degree of flexibility is provided so that you may disable some controllers in a subtree. For example: root ---> child1 (cpuset,memory,cpu) (cpuset,memory) \ \-> child2 (cpu) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/