Re: report a bug about sched_rt

[Tommaso Cucinotta]

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
http://feanor.sssup.it/~tommaso

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/