Re: report a bug about sched_rt

Tommaso Cucinotta
2009-07-25T23:24:30Z

Hi,

Jamie Lokier ha scritto:
> Raistlin wrote:
>
>>> http://feanor.sssup.it/~faggioli/papers/OSPERT-2009-dlexception.pdf
>>>
>> Moreover, we are open to any
>> suggestion and contribution about this work, especially from the
>> community!
>>
>
> The biggest weakness I see is if the application has a bug such as
> overwriting random memory or terminating the thread which is receiving
> timer signals, it can easily break the scheduling policy by accident.
>
> When the scheduling policy is implemented in the kernel, it can only
> be broken by system calls requesting a change of scheduling policy,
> which are relatively unlikely, and if necessary that can be completely
> prevented by security controls.
>
First, thanks for your comments and interest. The mentioned mechanism
should be regarded as something that helps in the development of
programs that need to meet timing requirements. This is not meant at all
to constitute a "user-level" scheduler, nor to replace a real-time
scheduler job. Contrarily, its purpose is solely to push towards a
software design paradigm in which the "awareness" of the existing timing
constraints, and the "awareness" of the possibility that they might be
violated (on a GPOS) is coded at the program-level (by means of an
exception-like paradigm). The mechanism has been designed as a
complement to the real-time scheduling facilities that the kernel
provides. As an example, imagine that, by a proper configuration of the
scheduling policy and parameters, an application may be guaranteed a
certain budget every period. However, the requested budget cannot be the
actual worst-case, because it would not be practical to compute it (nor
feasible, cause it would depend on a lot of external factors such as
interrupt load etc...) and it would lead to too much under-usage of
resources. By using this exception-like paradigm, the developer may
code, into an "exception-handler" segment, the recovery actions needed
whenever the real-time task is about to violate for example its WCET
constraints (for example, one could use a "try_wcet()" block with a WCET
specs which is slightly lower than the budget configured into the
scheduler, i.e., the difference being the WCET of the exception handling
code). Then, the real-time scheduler will still enforce the configured
budget for this application, so, if the recovery logics embedded inside
the exception-handler takes too much (i.e., its WCET has been
under-estimated), then the temporal isolation is guaranteed anycase, and
the application won't impact negatively other applications' real-time
guarantees provided by the scheduler.
In fact, we're working on a practical case-study where both the
timing-exception mechanism and one of the real-time schedulers we have
here at SSSA is used. For example, a potential issue we're thinking
about is if and how to "synchronize" someway the vision of time of the
exception-based mechanism and the one of the scheduler, because in prior
experiences built modifying multimedia applications for taking advantage
of feedback-based real-time scheduling, this was one of the burden to
face with, before the application started behaving as "theoretically"
foreseen.

Hope this clarifies our view. Please, feel free to post further comments.

Regards,

T.