From: Thomas Gleixner <tglx@linutronix.de>
To: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Zefan Li <lizefan@huawei.com>,
Mike Galbraith <umgwanakikbuti@gmail.com>,
Ingo Molnar <mingo@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: Wed, 6 May 2015 11:12:45 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1505061100040.4225@nanos> (raw)
In-Reply-To: <20150505190048.GY1971@htj.duckdns.org>
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 somewhere, then we need to
> > fix that and make them consistent and understandable and not replace
> > them by half baken heuristics which postpone the failure to some point
> > where it is even less understandable.
>
> There are no such magic heuristics because controllers need well
> defined behaviors when current is above limit anyway and behave
> exactly the same way no matter how that state is reached. For
How would something go above limit in the first place if your resource
management is done proper?
If a group has a resource limit, then it is not allowed to exceed
that resource. So any attempt to use more resources must fail,
period. There is no way to go above the limit.
If you try to lower the limits of an existing group below the level
which is already used, then this limit restriction attempt must
fail.
That's the basic principle of resource management. And if you try to
avoid them, then you have a massive design failure. It's that simple.
Thanks,
tglx
next prev parent reply other threads:[~2015-05-06 9:12 UTC|newest]
Thread overview: 28+ 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
[not found] ` <5546C34C.7050202-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-05-04 3:13 ` Mike Galbraith
[not found] ` <1430709236.3129.42.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-04 4:39 ` Zefan Li
[not found] ` <5546F80B.3070802-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-05-04 5:10 ` Mike Galbraith
[not found] ` <1430716247.3129.44.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-04 5:39 ` Mike Galbraith
[not found] ` <1430717964.3129.62.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-04 9:11 ` Zefan Li
[not found] ` <554737AE.5040402-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-05-04 12:08 ` Mike Galbraith
2015-05-04 12:37 ` Peter Zijlstra
2015-05-04 14:09 ` Mike Galbraith
[not found] ` <1430748582.3166.16.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-05 3:46 ` Zefan Li
[not found] ` <55483CF8.8030908-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2015-05-05 6:02 ` Mike Galbraith
[not found] ` <20150504123738.GZ21418-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
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
[not found] ` <20150505190057.GR23123-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2015-05-05 19:06 ` Tejun Heo
[not found] ` <20150505190603.GZ1971-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
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-06 9:12 ` Thomas Gleixner [this message]
2015-05-05 18:31 ` 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=alpine.DEB.2.11.1505061100040.4225@nanos \
--to=tglx@linutronix.de \
--cc=cgroups@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox