All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zefan Li <lizefan@huawei.com>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>
Subject: Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach()
Date: Mon, 4 May 2015 17:11:10 +0800	[thread overview]
Message-ID: <554737AE.5040402@huawei.com> (raw)
In-Reply-To: <1430717964.3129.62.camel@gmail.com>

>>> 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...


WARNING: multiple messages have this Message-ID (diff)
From: Zefan Li <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Mike Galbraith <umgwanakikbuti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach()
Date: Mon, 4 May 2015 17:11:10 +0800	[thread overview]
Message-ID: <554737AE.5040402@huawei.com> (raw)
In-Reply-To: <1430717964.3129.62.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

>>> 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...

  reply	other threads:[~2015-05-04 10:23 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-04  0:54 [PATCH] sched: Relax a restriction in sched_rt_can_attach() Zefan Li
2015-05-04  0:54 ` Zefan Li
2015-05-04  3:13 ` Mike Galbraith
2015-05-04  3:13   ` Mike Galbraith
2015-05-04  4:39   ` Zefan Li
2015-05-04  4:39     ` Zefan Li
2015-05-04  5:10     ` Mike Galbraith
2015-05-04  5:10       ` Mike Galbraith
2015-05-04  5:39       ` Mike Galbraith
2015-05-04  5:39         ` Mike Galbraith
2015-05-04  9:11         ` Zefan Li [this message]
2015-05-04  9:11           ` Zefan Li
2015-05-04 12:08           ` Mike Galbraith
2015-05-04 12:08             ` Mike Galbraith
2015-05-04 12:37           ` Peter Zijlstra
2015-05-04 12:37             ` Peter Zijlstra
2015-05-04 14:09             ` Mike Galbraith
2015-05-05  3:46               ` Zefan Li
2015-05-05  3:46                 ` Zefan Li
2015-05-05  6:02                 ` Mike Galbraith
2015-05-05  6:02                   ` Mike Galbraith
2015-05-05  3:54             ` Zefan Li
2015-05-05  3:54               ` Zefan Li
2015-05-05 14:10               ` Peter Zijlstra
2015-05-05 14:18                 ` Tejun Heo
2015-05-05 15:19                   ` Peter Zijlstra
2015-05-05 16:31                     ` Tejun Heo
2015-05-05 19:00                       ` Peter Zijlstra
2015-05-05 19:06                         ` Tejun Heo
2015-05-05 19:06                           ` Tejun Heo
2015-05-06  8:49                           ` Peter Zijlstra
2015-05-06  8:49                             ` Peter Zijlstra
2015-05-05 14:41             ` Tejun Heo
2015-05-05 15:11               ` Peter Zijlstra
2015-05-05 16:13                 ` Tejun Heo
2015-05-05 16:50                   ` Peter Zijlstra
2015-05-05 18:29                     ` Thomas Gleixner
2015-05-05 19:00                       ` Tejun Heo
2015-05-05 19:00                         ` Tejun Heo
2015-05-06  9:12                         ` Thomas Gleixner
2015-05-05 18:31                     ` Tejun Heo
2015-05-05 14:09         ` Tejun Heo
2015-05-05 14:09           ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=554737AE.5040402@huawei.com \
    --to=lizefan@huawei.com \
    --cc=cgroups@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    --cc=umgwanakikbuti@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.