On Tue, 5 May 2015, Tejun Heo wrote:
> On Tue, May 05, 2015 at 08:29:28PM +0200, Thomas Gleixner wrote:
> > As Peter said several times: hard failure is good and desired. It's a
> > very clear information on which people can act on. If the failures
> > modes are nilly-willy today, as you wrote some
On Tue, May 05, 2015 at 03:06:03PM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, May 05, 2015 at 09:00:57PM +0200, Peter Zijlstra wrote:
> > On Tue, May 05, 2015 at 12:31:12PM -0400, Tejun Heo wrote:
> > > What I don't want to happen is controllers failing migrations
> > > willy-nilly for ra
Hello, Peter.
On Tue, May 05, 2015 at 09:00:57PM +0200, Peter Zijlstra wrote:
> On Tue, May 05, 2015 at 12:31:12PM -0400, Tejun Heo wrote:
> > What I don't want to happen is controllers failing migrations
> > willy-nilly for random reasons leaving users baffled, which we've
> > actually been doing
On Tue, May 05, 2015 at 12:31:12PM -0400, Tejun Heo wrote:
>
> What I don't want to happen is controllers failing migrations
> willy-nilly for random reasons leaving users baffled, which we've
> actually been doing unfortunately. Maybe we need to deal with this
> fixed resource arbitration as a s
Hello, Thomas.
On Tue, May 05, 2015 at 08:29:28PM +0200, Thomas Gleixner wrote:
> I fully agree and after reading through this thread I really have to
> say that this whole notion of relax the admission control and then try
> to magically converge to the resource limits is horrible in all
> aspect
Hello, again.
On Tue, May 05, 2015 at 06:50:06PM +0200, Peter Zijlstra wrote:
> I really don't get what you're saying there. If its not allowed to
> 'escape' there must be some equivalent of can_attach().
>
> Otherwise you simply cannot reject the move.
A given user isn't allowed to move process
On Tue, 5 May 2015, Peter Zijlstra wrote:
> On Tue, May 05, 2015 at 12:13:35PM -0400, Tejun Heo wrote:
> > On Tue, May 05, 2015 at 05:11:13PM +0200, Peter Zijlstra wrote:
> > >
> > > So no; hard failure is good and desired. It allows guarantees, which is
> > > a good and desired feature of control
Hello, Peter.
On Tue, May 05, 2015 at 04:10:49PM +0200, Peter Zijlstra wrote:
> Imagine:
>
> root
>/\
> A B
>/ \/ \
> a1 a2 b1 b2
>
> Now if they all have -1, I cannot set a bw on any except the leaf nodes
> ([ab][12]). Because the sum of child b
Hello, Peter.
On Mon, May 04, 2015 at 02:37:38PM +0200, Peter Zijlstra wrote:
> > 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
On Tue, May 05, 2015 at 10:41:04AM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Mon, May 04, 2015 at 02:37:38PM +0200, Peter Zijlstra wrote:
> > > 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
>
On Tue, May 05, 2015 at 10:18:38AM -0400, Tejun Heo wrote:
> > Now you can kludge around some of this, for example you can make the
> > default depend on the parent setting etc.. But that's horribly
> > inconsistent.
>
> I don't think we can kludge this. For all other resources, we're
> defining
On Tue, May 05, 2015 at 12:13:35PM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, May 05, 2015 at 05:11:13PM +0200, Peter Zijlstra wrote:
> ...
> > But but but... that doesn't make any damn sense! Why would you want to
> > do something mad like that?
> >
> > To me the organization is very mu
Hello, Peter.
On Tue, May 05, 2015 at 05:19:49PM +0200, Peter Zijlstra wrote:
> > I don't think we can kludge this. For all other resources, we're
> > defining the limits that can't be crossed so nesting them w/ -1 by
> > default is fine. RR slices are different it that we're really slicing
> >
Hello, Peter.
On Tue, May 05, 2015 at 05:11:13PM +0200, Peter Zijlstra wrote:
...
> But but but... that doesn't make any damn sense! Why would you want to
> do something mad like that?
>
> To me the organization is very much part of the control structure. It
> cannot be an invariant. Treating it
On Tue, May 05, 2015 at 11:54:31AM +0800, Zefan Li wrote:
> But I was wondering if we can change the default value of cpu.rt_runtime_us
> from 0 to -1? So by default the RT tasks can be attached to a newly-created
> cgroup without users having to make any configuration, and those tasks are
> confi
Hello, Mike.
On Mon, May 04, 2015 at 07:39:24AM +0200, Mike Galbraith 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)
On Tue, 2015-05-05 at 11:46 +0800, Zefan Li wrote:
> On 2015/5/4 22:09, Mike Galbraith wrote:
> > On Mon, 2015-05-04 at 14:37 +0200, Peter Zijlstra wrote:
> >> On Mon, May 04, 2015 at 05:11:10PM +0800, Zefan Li wrote:
> >>
> >>> Some degree of flexibility is provided so that you may disable some
>
On 2015/5/4 20:37, Peter Zijlstra wrote:
> On Mon, May 04, 2015 at 05:11:10PM +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,
On 2015/5/4 22:09, Mike Galbraith wrote:
> On Mon, 2015-05-04 at 14:37 +0200, Peter Zijlstra wrote:
>> On Mon, May 04, 2015 at 05:11:10PM +0800, Zefan Li wrote:
>>
>>> Some degree of flexibility is provided so that you may disable some
>>> controllers
>>> in a subtree. For example:
>>>
>>> root
On Mon, 2015-05-04 at 14:37 +0200, Peter Zijlstra wrote:
> On Mon, May 04, 2015 at 05:11:10PM +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,memor
On Mon, May 04, 2015 at 05:11:10PM +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)
> \
>
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)
> >>>
>>> 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
>>>
On Mon, 2015-05-04 at 07:10 +0200, Mike Galbraith wrote:
> On Mon, 2015-05-04 at 12:39 +0800, Zefan Li wrote:
>
> > >> 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
> > >> restrictio
On Mon, 2015-05-04 at 12:39 +0800, Zefan Li wrote:
> >> 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 ov
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
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_GROU
27 matches
Mail list logo
