From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752691AbbEDMIl (ORCPT ); Mon, 4 May 2015 08:08:41 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:35645 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752222AbbEDMId (ORCPT ); Mon, 4 May 2015 08:08:33 -0400 Message-ID: <1430741313.3096.71.camel@gmail.com> Subject: Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach() From: Mike Galbraith To: Zefan Li Cc: Ingo Molnar , Peter Zijlstra , Tejun Heo , LKML , Cgroups Date: Mon, 04 May 2015 14:08:33 +0200 In-Reply-To: <554737AE.5040402@huawei.com> References: <5546C34C.7050202@huawei.com> <1430709236.3129.42.camel@gmail.com> <5546F80B.3070802@huawei.com> <1430716247.3129.44.camel@gmail.com> <1430717964.3129.62.camel@gmail.com> <554737AE.5040402@huawei.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2015-05-04 at 17:11 +0800, Zefan Li wrote: > >>> 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) > >> > >> Whew, that's a relief. Thanks. > > > > But somehow I'm not feeling a whole lot better. > > > > "May" means if you don't explicitly take some action to disable group > > scheduling, you get it (I don't care if I have an off button), but that > > would also seemingly mean that we would then have rt tasks in taskgroups > > with no bandwidth allocated, ie you have to make group scheduling for rt > > tasks meaningless until a bandwidth appeared, and to make bandwidth > > appear, you'd have to stop the world, distribute, continue, no? > > > > The current "just say no" seems a lot more sensible. > > > > I just realized we allow removing/adding controllers from/to cgroups > while there are tasks in them, which isn't safe unless we eliminate all > can_attach callbacks. We've done so for some cgroup subsystems, but > there are still a few of them... I was pondering the future (or so I thought), but seems it turned into the past while I wasn't looking. Oh well, you found a bug anyway. -Mike