Gilles Chanteperdrix wrote:
> Henri Roosen wrote:
>> Did some more tracing to see why the lower priority thread is
>> scheduled before the higher prio thread is ended.
>>
>> The highest priority task makes a system call and gets relaxed by
>> xnshadow_relax. The rpi is pushed here and a Linux call with
>> LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
>> ROOT task. So far so good!
>>
>> In the Linux domain, we run into the lostage_handler, where the
>> scheduled LO_WAKEUP_REQ is executed. Here there is a call to
>> xnpod_schedule() which actually causes a switch back to the primary
>> domain and the lower priority Xenomai task to be scheduled in, even
>> before the wanted process is woken up.
>>
>> Now, I am unsure what is faulty here and maybe Philippe or someone can
>> answer that. Personally I would have expected the xnpod_schedule (or
>> xnsched_pick_next) to know about the rpi list and not schedule a lower
>> priority task than of any on that list. I was unable to find such
>> code.
>>
>
> Unless I am wrong, what happens is whait is intended, at least if we
> read the comment:
> case LO_WAKEUP_REQ:
> /*
> * We need to downgrade the root thread
> * priority whenever the APC runs over a
> * non-shadow, so that the temporary boost we
> * applied in xnshadow_relax() is not
> * spuriously inherited by the latter until
> * the relaxed shadow actually resumes in
> * secondary mode.
> */
> rpi_clear_local(xnshadow_thread(current));
> xnpod_schedule();
>
> Which means that we do not want other Linux kernel code than the
> real-time thread itself to inherit from this thread priority. Except
> that all the code from the switch to root thread to the lostage_handler
> (which means any Linux currently preempted critical section) already
> inherited the priority.
The problem is that calling wake_up_process (a bit below that code) does
not guarantee that the next thread scheduled is the shadow running in
secondary mode. There may be other Linux threads with higher priorities,
and we do not want them to inherit this priority. The idea is that if
the next process scheduled is indeed the real-time shadow running in
secondary mode, the RPI will be applied in do_schedule_event. But of
course, this leaves a window for another real-time thread to preempt. At
least it is the way I would understand this, but I am not sure I
understand RPI all that well, so, I will shut up and let Philippe answer.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
