Re: [Xenomai-core] [RFC] non-RT-safe rtdm_event_*wait

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Given that, a shadow thread which remains in secondary mode is seen as
>>suspended by the Xenomai scheduler, which means that the additional
>>overhead is close to nil (aside of an additional shadow tcb), until it
>>tries to grab the resource and thus moves to the primary domain, just
>>for going to sleep.
> 
> 
> I'm not concerned about a passive shadow, my aim is to reduce the impact
> of active shadow threads without strict timing requirements. When there
> is a larger number of them, they should not influence RT scheduling
> significantly for just being woken up.
> 

This issue already exists now, since interrupts are off when Linux 
performs a context switch, so that we can't wreck the whole thing by 
allowing a shadow to preempt it in the middle of the mm switch. Since 
non-RT shadow would run at priority level 0, my feeling is that it would 
not change the current situation, except perhaps on SMP where the nklock 
would be held a little more.

> The other point might be the code path length of both non-RT wakeup
> suspend/wakeup mechanisms. It's only an assessment, but I think this way
> would be shorter. Anyway, numbers would speak clearer, and I guess this
> should be done first before any further design decision.
> 

Agreed.

> 
>>IOW, I would rather use the allow-non-SCHED_FIFO-shadow patch to allow
>>regular Linux tasks to pend seamlessly on Xenomai sync objects as true
>>shadows, and add to the rtdm blocking syscall handler some code that
>>would transparently promote any calling regular task as a Xenomai shadow
>>on the fly, before undergoing the request. The other advantage of such
>>approach is that the non-RT pending task is still known from the Xenomai
>>sub-system (/proc/xenomai/ interface and so on), which may be useful
>>given that it interacts with it. You could still apply a FIFO pending
>>order with mixed RT and non-RT tasks the same way.
> 
> 
> Hmm, on-demand shadowing might be an option. Ok, once non-SCHED_FIFO is
> merged, we should have a look at both approaches from the performance
> POV and compare potential differences with the required additional code.
> 
> 
>>Moving RTDM to native preemption would also be simpler, since RTDM would
>>expect the issue to be handled at core level directly, and in the
>>preempt-rt case, the issue of the caller's domain is actually a non-issue.
>>
> 
> 
> Well, this is already the case for my proposal: no special handling of
> rtdm_event_* depending on the caller's context anymore.
> 

But still, you have to change RTDM's code do implement that, more than 
you would have to do in promoting a regular task as a non-RT shadow.

> Jan
> 


-- 

Philippe.