Re: [Xenomai-help] pit

[Philippe Gerum <rpm@xenomai.org>]

Steven Seeger wrote:
> I compiled the kernel for 586 and am running the PIT timer. I still get
> the 17000-18000 context switches per second, and now the irq0 handler is
> taking up 11% of the CPU instead of only 5% when the two 8000Hz tasks
> are loaded but delayed on events. I think that the problem isn’t with
> pit, but with the tasks being periodic even though they are blocked.
>

RTAI (at least the version you used) has a single per-task internal
timer, which is not really a timer, but rather a "resume_time" field,
the RTAI core is directly testing to know whether it should wake up a
delayed task.

Therefore, if your task used to call rt_task_make_periodic() on RTAI,
then just blocked on a semaphore with no timeout value, then this task
was dequeued from the timed task list, and for that reason, no oneshot
timer ticks had to be programmed to wake it up anymore. The drawback is
that you have no timer object, independent from the task itself.
Everything has to be related to this single "resume_time" field, on a
per-task basis. This is why the RTAI core has to save and restore this
value when nesting some timed operations for instance.

Xenomai has independent timers, which also means that if you call
rt_task_set_periodic() on a task, it will arm an internal per-task timer
(thread->ptimer) which will tick independently, regardless of what your
task is currently doing. So you will have timer ticks fired for that
task, even if it is blocked on some synchro with no timeout, in which
case, the tick handler will attempt to resume the task, but since the
DELAYED+BLOCKED wait states are conjunctive, it won't be able to.

I'd suggest that you choose whether your task has to undergo a periodic
timeline or not, i.e. whether it should call rt_task_wait_period() to
wait for the next timeslot, or block on some synchronization object to
resume its processing for the current period. Using both is one too many.

>  
> 
> Running in PIT mode with periodic timing on uses only 9.5% of the CPU. I
> show about 9000 context switches per second. (the 2 8000 hz tasks and
> the 1000 hz linux interrupt.)
> 
>  
> 
> With periodic timing, it’s 5.4% when the tasks idle and about 9000
> context switches a second. When one of them becomes active, the irq0
> handler is using 10% of the CPU and the sound task is using about 8%.
> These are two kernel tasks.
> 
>  
> 
> Userspace stack size is set to 64k. I forgot to mention this to Philippe
> earlier.
> 
>  
> 
> Perhaps the problem is the overhead that the timer handler introduces
> being able to support multiple skins with individual timebases. It
> sounds like in order to save some cpu cycles, I may want to turn off
> periodicity while threads are idle and also avoid setting threads
> periodic when they can be driven some other way.
> 
>  
> 
> Steven
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.