Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2993856AbbEEQGf (ORCPT ); Tue, 5 May 2015 12:06:35 -0400 Received: from mail-qg0-f51.google.com ([209.85.192.51]:36747 "EHLO mail-qg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993152AbbEEOSn (ORCPT ); Tue, 5 May 2015 10:18:43 -0400 Date: Tue, 5 May 2015 10:18:38 -0400 From: Tejun Heo To: Peter Zijlstra Cc: Zefan Li , Mike Galbraith , Ingo Molnar , LKML , Cgroups Subject: Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach() Message-ID: <20150505141838.GR1971@htj.duckdns.org> References: <5546C34C.7050202@huawei.com> <1430709236.3129.42.camel@gmail.com> <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> <55483EF7.7070905@huawei.com> <20150505141049.GN21418@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150505141049.GN21418@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1836 Lines: 53 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 bw must strictly be smaller or > equal to the parent bandwidth, and -1 if effective inf. > > Similarly, if A has bw enabled I cannot create a new child with -1. > Because above. > > 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 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 up and guaranteeing a portion of something finite, so unlimited by default thing doesn't really work here. > So I really prefer not to go that way; if people use RR/FIFO they had > better bloody know what they're doing; which includes setting up the > system. The problem is that this is tied to the normal cpu controller. Users who don't have any intention of mucking with RT scheduling end up being dragged into it. Given the strict nature of RR slicing, I'm don't even think it's actually useful to make the slicing hierarchical. From cgroup's POV, it'd be best if RR slicing can be detached. > The whole RR/FIFO thing is so enormously broken (by definition; this > truly is unfixable) that you simply _cannot_ automate it. Yeah, exactly. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/