linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.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: Tue, 5 May 2015 20:29:28 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1505052007140.4225@nanos> (raw)
In-Reply-To: <20150505165006.GR21418@twins.programming.kicks-ass.net>

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.
> > 
> > Isn't that too sweeping a statement?  We want them in some places but
> > not necessarily in all places.  The hard failures aren't going away.
> > They're just localized to specific areas where they're easier to
> > handle.
> 
> Easier how? I'm really not seeing how any of this is making things
> easier for anybody.
> 
> All I'm seeing is that you're making cgroups useless for people who want
> to guarantee things (eg. the realtime people).

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

Hierarchies must have a strictly inherited and overall consistent
resource management and therefor resource limitation. Otherwise they
are just useless.

The idea of allowing overcommitment and magically converging to back
to the limits yells heuristics all over the place and we all know how
reliable heuristics are.

Tejun, you try to make the whole configuration and placement simpler
for the user, but all you achieve is that you act like all these
politicians who promise tax cuts and whatever and forget about them
once the elections are over. How is that going to make stuff simpler
for users/admins? Not at all.

Instead of failing hard at placement/configuration time they get
surprised by hard to understand fallout of magic convergence
heuristics. That's crap and no matter how you argue it stays crap.

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.

If there are issues with run-away problems, i.e. upping a resource
limit which gets eaten up from the existing tasks before you can admit
a new one, then your magic convergence thing is again the wrong
answer. The right approach is:

      1) Up the limit and make a reservation at the same time
      2) Admit the new task and allow it to consume the reservation
      3) Set it effective

You can apply this to ALL sorts of resource controllers and you give
the user a very simple to understand mechanism to control and
configure his system.

> Are you really going to force us to abandon cgroups and invent yet
> another grouping thing?

Sigh no. I think cgroups can be fixed, if we just adhere to the basic
principles of hierarchical resource management and remove/reject all
magic "we'll fix that for you" nonsense.

Thanks,

	tglx

  reply	other threads:[~2015-05-05 18:29 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
2015-05-04  3:13 ` Mike Galbraith
2015-05-04  4:39   ` Zefan Li
2015-05-04  5:10     ` Mike Galbraith
2015-05-04  5:39       ` Mike Galbraith
2015-05-04  9:11         ` Zefan Li
2015-05-04 12:08           ` Mike Galbraith
2015-05-04 12:37           ` Peter Zijlstra
2015-05-04 14:09             ` Mike Galbraith
2015-05-05  3:46               ` Zefan Li
2015-05-05  6:02                 ` Mike Galbraith
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-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 [this message]
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

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.1505052007140.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;
as well as URLs for NNTP newsgroup(s).