Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach()

[Thomas Gleixner]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/