[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FC4BE9F.9060102@gmail.com>
Date: Tue, 29 May 2012 14:18:39 +0200
From: Juri Lelli <juri.lelli@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: tglx@...utronix.de, mingo@...hat.com, rostedt@...dmis.org,
oleg@...hat.com, fweisbec@...il.com, darren@...art.com,
johan.eker@...csson.com, p.faure@...tech.ch,
linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
michael@...rulasolutions.com, fchecconi@...il.com,
tommaso.cucinotta@...up.it, nicola.manica@...i.unitn.it,
luca.abeni@...tn.it, dhaval.giani@...il.com, hgu1972@...il.com,
paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
insop.song@...csson.com, liming.wang@...driver.com,
jkacur@...hat.com, harald.gustafsson@...csson.com
Subject: Re: [PATCH 13/15] sched: add bandwidth management for sched_dl.
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists