Module: xenomai-2.5
Branch: master
Commit: c8a0f8cb1bbda978dc8c4b1754eb6526861b4c73
URL:
http://git.xenomai.org/?p=xenomai-2.5.git;a=commit;h=c8a0f8cb1bbda978dc8c4b1754eb6526861b4c73
Author: Jan Kiszka <jan.kis...@siemens.com>
Date: Sun May 2 03:14:40 2010 +0200
nucleus: fix excessive host tick latencies
If a reschedule is pending, we won't allow the host timer to decide
about the next hardware tick. But if that next reschedule will simply
keep ROOT (which, e.g., happens during thread deletion), this deferral
can impose significant unwanted timer latencies on Linux.
---
ksrc/nucleus/pod.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 3ffd548..fb63f35 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -2184,9 +2184,16 @@ void __xnpod_schedule(struct xnsched *sched)
zombie = xnthread_test_state(curr, XNZOMBIE);
next = xnsched_pick_next(sched);
- if (next == curr && !xnthread_test_state(curr, XNRESTART))
+ if (next == curr && !xnthread_test_state(curr, XNRESTART)) {
/* Note: the root thread never restarts. */
+ if (unlikely(xnthread_test_state(next, XNROOT))) {
+ if (testbits(sched->status, XNHTICK))
+ xnintr_host_tick(sched);
+ if (testbits(sched->status, XNHDEFER))
+ xntimer_next_local_shot(sched);
+ }
goto signal_unlock_and_exit;
+ }
XENO_BUGON(NUCLEUS, need_resched == 0);
_______________________________________________
Xenomai-git mailing list
Xenomai-git@gna.org
https://mail.gna.org/listinfo/xenomai-git
