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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3341 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> attached is an experimental patch to allow blocking from non-RT context
>> on RTDM events. Petr Cervenka made me think about this extension which
>> could partially open RTDM drivers also for non-shadowed, i.e. standard
>> Linux tasks.
>>
>> Why not simply shadowing non-RT waiters? Because this kind of sync
>> support should be cheaper than adding yet another (though low-prio) task
>> to the real-time domain ("should" == I didn't benchmark my believe). And
> 
> I would rather move the logic to the sync object at nucleus level since
> it's a useful feature for all skins, but doing so, we would also drag a
> fair amount of complexity just for the sake of not having to shadow a
> Linux task. IMHO, leaving this at the skin level forks the
> implementation of the synchronization management, which raises the issue
> of duplicating functionalities only depending on the calling context.
> 
> Looking at the issue differently, we already know that we could shadow
> SCHED_NORMAL/SCHED_OTHER threads without promoting them to the
> SCHED_FIFO class - you actually submitted this patch, and it's waiting
> for -rc2 to be released before I merge it into mainline.
> 
> 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.

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.

> 
> 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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]