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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
