On 01/03/06, Philippe Gerum <[EMAIL PROTECTED]> wrote:
I definitely agree with you here.
IMHO, there is no point in calling rt_task_wait_period() a few
times in a row just to clean up the "poverrun" counter
(if there were a few overruns) when the whole may be reported at once. This former way just gives unnecessary overhead.
Actually, there is a kind of application that must not rely on
the "poverrun" counter, the klatency/latency utility and alike.
They are run normally (at least at the very first time) in the untrusted environment
where SMI or something similar - that may prevent a CPU from handling normal
interrupts for quite a long time - make occur happily.
As the "poeverrun" counting is dependent on the timer interrupt,
it becomes irrelevant.
Something like
overruns = (real_time_of_wakeup - desired_time_of_wakeup) / period (*)
should be rather used there (of course, the timing source must not be
interrupt-dependent).
Other applications may likely rely on the "poverrun" counter
(returned by rt_task_wait_period(&overrun)) as they normally
run in the (more or less) studied and tweaked environment.
Ok, some "paranoid" programmers would think differently even then
but there is always the (*) way :o)
The other option I've described for
dealing with overruns in rt_task_wait_period would be as follows:
- save the count of overruns
- clear the count of overruns /* i.e. "purge" */
- return both the saved count and -ETIMEDOUT to the user.
This way, rt_task_wait_period would return only once with an error status, telling
the user about the exact count of pending overruns in the same time.
I definitely agree with you here.
IMHO, there is no point in calling rt_task_wait_period() a few
times in a row just to clean up the "poverrun" counter
(if there were a few overruns) when the whole may be reported at once. This former way just gives unnecessary overhead.
Actually, there is a kind of application that must not rely on
the "poverrun" counter, the klatency/latency utility and alike.
They are run normally (at least at the very first time) in the untrusted environment
where SMI or something similar - that may prevent a CPU from handling normal
interrupts for quite a long time - make occur happily.
As the "poeverrun" counting is dependent on the timer interrupt,
it becomes irrelevant.
Something like
overruns = (real_time_of_wakeup - desired_time_of_wakeup) / period (*)
should be rather used there (of course, the timing source must not be
interrupt-dependent).
Other applications may likely rely on the "poverrun" counter
(returned by rt_task_wait_period(&overrun)) as they normally
run in the (more or less) studied and tweaked environment.
Ok, some "paranoid" programmers would think differently even then
but there is always the (*) way :o)
--
Best regards,
Dmitry Adamushko
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
