On Thu, Mar 31, 2011 at 4:28 PM, Gilles Chanteperdrix <[email protected]> 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. > > -- > Gilles. >
Yes, I think too that what is coded here might be what is intended. Except the behavior that exactly at this xnpod_schedule() call the lower priority threads from the primary domain are scheduled in, while Priority Coupling promises to not schedule any of those before the higher priority relaxed thread. That is why I'm wondering where that specific code is, which I would expect somewhere down the line of xnpod_schedule() which would peek the rpi list or so. Or is it my misunderstanding to expect such code? Thanks, Henri _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
