[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <52E7F56A.7080707@sssup.it>
Date: Tue, 28 Jan 2014 18:22:34 +0000
From: Tommaso Cucinotta <tommaso.cucinotta@...up.it>
To: Peter Zijlstra <peterz@...radead.org>
CC: Luca Abeni <luca.abeni@...tn.it>, Henrik Austad <henrik@...tad.us>,
Juri Lelli <juri.lelli@...il.com>, 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, nicola.manica@...i.unitn.it,
dhaval.giani@...il.com, hgu1972@...il.com,
paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
insop.song@...il.com, liming.wang@...driver.com, jkacur@...hat.com,
harald.gustafsson@...csson.com, vincent.guittot@...aro.org,
bruce.ashfield@...driver.com, rob@...dley.net
Subject: Re: [PATCH] sched/deadline: Add sched_dl documentation
On 28/01/14 09:31, Peter Zijlstra wrote:
>> Exactly. I can remember also a huge period might be harmful, because with it
>> even a tiny utilization may lead to a big runtime that starves the whole non
>> RT tasks for a significant time.
>
> Another way to solve that is with explicit slack time scheduling, where
> slack here means the time/utilization not allocated to dl tasks (a quick
> google shows various different usages of slack, including laxity).
>
> So suppose we have 50% utilization but with a huge period, we could
> schedule the other 50% at a fixed but smaller period and have that run
> the rt/fair/etc tasks.
>
> So effectively we'll always fill up the utilization to 100% and use the
> 'slack' time as a server for the other classes.
Yesss :-)! Indeed, AFAICR in the AQuoSA API there was the QOS_F_DEFAULT flag
http://aquosa.sourceforge.net/aquosa-docs/aquosa-qosres/html/qos__types_8h_source.html
(that could only be set by a privileged process) just there to allow
for creating a server serving "default" tasks (namely, every non-aquosa task).
This way, you could create for example at system boot time a default
reservation with a precise (runtime, period) for Linux, so that non-aquosa
tasks could have a chance to run in that reservation, even in presence of
a RT reservation with a significantly long runtime.
T.
--
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