[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FC0B95C.5060207@gmail.com>
Date: Sat, 26 May 2012 13:07:08 +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.
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.
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