Re: report a bug about sched_rt

Tommaso Cucinotta
2009-07-25T14:58:21Z

Hi all,

Raistlin ha scritto:
>> For simple things like "try to keep the buffer to my DVD writer full"
>> (no I don't know how much CPU that requires - it's a kind of "best
>> effort but try very hard!"), it would be quite useful to have
>> something like RT-bandwidth which grants a certain percentage of time
>> as an RT task, and effectively downgrades it to SCHED_OTHER when that
>> time is exceeded to permit some fairness with the rest of the system
> Well, agree, again. If you want something very useful, you need the
> combination of the two: user space techniques and kernel space support.
>
I didn't follow the entire discussion, however I'd like to add a
comment, if it may be of any help. What is useful actually depends on
the usage scenario and its requirements, comprising for example
real-time and security requirements. On one hand, giving a real-time
task the opportunity to keep running even if its budget is exhausted may
be of course useful for the real-time task. In fact, in the real-time
literature, you can find the term "soft reservations" to denote those
real-time scheduling mechanisms that have such a property (and still
preserve theoretical schedulability), with various different ways of
distributing the spare capacity on the real-time tasks. On a GPOS like
Linux, it may also be useful to "downgrade" a RT task to SCHED_OTHER
when its budget is exhausted. In fact, in the AQuoSA EDF-based scheduler
[academic], if the flag "SOFT_SERVER" is specified when creating a
server, this is exactly what happens :-). On a related note, in the
POSIX SPORADIC_SERVER (and e.g., its implementation by Dario Faggioli)
there is a "low priority" field specifying the priority at which the
task should run when the budget is exhausted).
However, if you depart from the traditional "embedded" context (i.e.,
for industrial control), switching for example to a "multi-user server"
context, then a task "triggering" the throttling might not constitute
necessarily a system bug that "needs a reboot", but it may simply be due
to an application trying to over-use the system as compared to how much
it is supposed to use it. Imagine a "pay-per-compute" context in which
the share of a server is granted to a user (i.e., to a VM). Then, a
provider would not necessarily want to grant a user more computation
capability than the user has paid for. In fact, in the AQuoSA scheduler
[again, academic], an access-control model exists by which the sys-admin
may decide what users (and user groups) are authorized to access the
"SOFT_SERVER" facility (i.e., real-time reservations for "gold" users
might be allowed to be soft, but the ones for "bronze" users might not).

Therefore, IMHO there is no "silver bullet", but what behavior is best
depends on the security requirements that may be in-place. Access to the
"soft server" mentioned above is just an example, but plenty of other
issues may arise, including: maximum system capacity that users may be
authorized to occupy, maximum RT server periods that users may be
authorized to use (for not starving the background OS for too much),
minimum RT server period (for not causing too much scheduling overhead),
etc... A more detailed discussion about security requirements arising
when granting real-time facilities to unprivileged users on a GPOS may
be found in [1], in case anyone is interested.

Regards,

T.

[1] Tommaso Cucinotta "Access Control for Adaptive Reservations on
Multi-User Systems", in Proceedings of the 14th IEEE Real-Time and
Embedded Technology and Applications Symposium (RTAS 2008), St. Louis,
MO, United States, April 2008, available at:
http://feanor.sssup.it/~tommaso/publications/RTAS-2008.pdf

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003