Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753950Ab2E2MSs (ORCPT ); Tue, 29 May 2012 08:18:48 -0400 Received: from mail-ey0-f174.google.com ([209.85.215.174]:47343 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753916Ab2E2MSp (ORCPT ); Tue, 29 May 2012 08:18:45 -0400 Message-ID: <4FC4BE9F.9060102@gmail.com> Date: Tue, 29 May 2012 14:18:39 +0200 From: Juri Lelli User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Peter Zijlstra CC: tglx@linutronix.de, mingo@redhat.com, rostedt@goodmis.org, oleg@redhat.com, fweisbec@gmail.com, darren@dvhart.com, johan.eker@ericsson.com, p.faure@akatech.ch, linux-kernel@vger.kernel.org, claudio@evidence.eu.com, michael@amarulasolutions.com, fchecconi@gmail.com, tommaso.cucinotta@sssup.it, nicola.manica@disi.unitn.it, luca.abeni@unitn.it, dhaval.giani@gmail.com, hgu1972@gmail.com, paulmck@linux.vnet.ibm.com, raistlin@linux.it, insop.song@ericsson.com, liming.wang@windriver.com, jkacur@redhat.com, harald.gustafsson@ericsson.com Subject: Re: [PATCH 13/15] sched: add bandwidth management for sched_dl. References: <1337809375-24295-1-git-send-email-juri.lelli@gmail.com> <1337809375-24295-14-git-send-email-juri.lelli@gmail.com> <1337942292.9783.178.camel@laptop> <4FC0B95C.5060207@gmail.com> <1338285486.26856.16.camel@twins> In-Reply-To: <1338285486.26856.16.camel@twins> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2700 Lines: 65 On 05/29/2012 11:58 AM, Peter Zijlstra wrote: > On Sat, 2012-05-26 at 13:07 +0200, Juri Lelli wrote: >> Hi, >> >> On 05/25/2012 12:38 PM, Peter Zijlstra wrote: >>> On Wed, 2012-05-23 at 23:42 +0200, Juri Lelli wrote: >>>> +/* >>>> + * Coupling of -dl and -rt bandwidth. >>>> + * >>>> + * Here we check, while setting the system wide bandwidth available >>>> + * for -dl tasks and groups, if the new values are consistent with >>>> + * the system settings for the bandwidth available to -rt entities. >>>> + * >>>> + * IOW, we want to enforce that >>>> + * >>>> + * rt_bandwidth + dl_bandwidth<= 100% >>>> + * >>>> + * is always true. >>>> + */ >>> >>> I was thinking we could do it the other way around, have have >>> dl_bandwidth included in rt_bandwidth. >>> >> >> If I understand correctly, you are proposing to treat -dl tasks as a >> special case of "real-time" tasks. Then we could reserve some bw to >> "real-time" (rt_bandwidth cap) activities and give a piece of this >> bw to -dl tasks (what remains is for -rt tasks). This is in principle >> nice and useful, but I'm not quite sure that this is the right point >> to achieve this logical behavior. >> I mean, -dl and -rt tasks are separately treated, so it is probably >> cleaner to manage their knobs separately. They have to coexist rather >> than be considered one a sub-case of the other. A better way to go >> for a common cap for them is probably the (long-term) hierarchical >> scheduling mechanism. >> >> So, I would prefer to keep the interface as is for now, but I can also >> completely misunderstood your thoughts :-P. > > The thing is, keeping it separate makes for an impossible configuration > scenario. Esp. once we enable !root usage. The proposed 5% is very > limiting and regular users won't have sufficient privilege to change it. > Ok, now I understand your point better, and I agree that 5% is hardly usable for !root users. However, I also think this is probably more a system admin problem. I mean, a sys admin that wants his users to play with -deadline scheduling should have thought how to properly set up his system, and the fact that something must be configured by hand to give users a usable system is generally not a so bad idea. > Also lowering FIFO/RR by default isn't a real option since people expect > that to get all time already (however silly that expectation is). > I agree. Don't want to spoil users expectations :-). Thanks and regards, - Juri -- 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/