From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752306AbbEFJNA (ORCPT ); Wed, 6 May 2015 05:13:00 -0400 Received: from www.linutronix.de ([62.245.132.108]:54894 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274AbbEFJM6 (ORCPT ); Wed, 6 May 2015 05:12:58 -0400 Date: Wed, 6 May 2015 11:12:45 +0200 (CEST) From: Thomas Gleixner To: Tejun Heo cc: Peter Zijlstra , Zefan Li , Mike Galbraith , Ingo Molnar , LKML , Cgroups Subject: Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach() In-Reply-To: <20150505190048.GY1971@htj.duckdns.org> Message-ID: References: <5546F80B.3070802@huawei.com> <1430716247.3129.44.camel@gmail.com> <1430717964.3129.62.camel@gmail.com> <554737AE.5040402@huawei.com> <20150504123738.GZ21418@twins.programming.kicks-ass.net> <20150505144104.GS1971@htj.duckdns.org> <20150505151113.GP21418@twins.programming.kicks-ass.net> <20150505161335.GT1971@htj.duckdns.org> <20150505165006.GR21418@twins.programming.kicks-ass.net> <20150505190048.GY1971@htj.duckdns.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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