[Xenomai] ipipe + PREEMPT_RT

[Xenomai] ipipe + PREEMPT_RT

[Mike Galbraith]

(oops, sent before subscription confirmation.. wash/rinse/repeat)

Greetings,

Seeing PREEMPT_RT in ipipe source, I got curious, extracted 4.4.43, and
wedged it into 4.4.54-rt, but there are a couple places that replace a
 spinlock_t (not raw) with an ipipe_spinlock_t, which cause build woes
for PREEMPT_RT.  I ifdefed those problematic spots back to spinlock_t
for grins, and surprisingly, my x64_64 desktop box booted, and does a
decent impersonation of a functional box.. which left me wondering
whether there's a preparatory patch for PREEMPT_RT somewhere, or
whether the PREEMPT_RT bits are WIP (or leftovers).

	-Mike   

Re: [Xenomai] ipipe + PREEMPT_RT

[Jan Kiszka]

On 2017-03-18 07:09, Mike Galbraith wrote:
> (oops, sent before subscription confirmation.. wash/rinse/repeat)
> 
> Greetings,
> 
> Seeing PREEMPT_RT in ipipe source, I got curious, extracted 4.4.43, and
> wedged it into 4.4.54-rt, but there are a couple places that replace a
>  spinlock_t (not raw) with an ipipe_spinlock_t, which cause build woes
> for PREEMPT_RT.  I ifdefed those problematic spots back to spinlock_t
> for grins, and surprisingly, my x64_64 desktop box booted, and does a
> decent impersonation of a functional box.. which left me wondering
> whether there's a preparatory patch for PREEMPT_RT somewhere, or
> whether the PREEMPT_RT bits are WIP (or leftovers).

A couple of times, I-pipe with Xenomai has been used in combination with
PREEMPT-RT. That basically created 3 prio groups: regular Linux tasks,
real-time Linux tasks hardened by PREEMPT-RT and above that
I-pipe/Xenomai. However, the integration of both patches was never
really fun.

Some fragments of those efforts you still find in the code, but I think
they haven't been stressed for a while. And, as you noticed, they do not
work as-is. I wouldn't be surprised if your ad-hoc fix does not yet
solve the issue, and a Xenomai use case would break. The semantics of
each real-time patch set is already tricky on its own...

That said, I suppose such integration will return automatically once
PREEMPT-RT makes it upstream.

Was your question just out or curiosity, or is there a potential use case?

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20170318/d84d2945/attachment.sig>

Re: [Xenomai] ipipe + PREEMPT_RT

[Mike Galbraith]

On Sat, 2017-03-18 at 09:45 +0100, Jan Kiszka wrote:

> Was your question just out or curiosity, or is there a potential use case?

Yeah, curiosity, thinking of possibilities.  I saw the PREEMPT_RT bits.
and was pondering the prospect of having a co-kernel available in big
boxen for large RT loads having a subset with very tight constraints.

	-Mike

Re: [Xenomai] ipipe + PREEMPT_RT

[Philippe Gerum]

On 03/18/2017 07:09 AM, Mike Galbraith wrote:
> (oops, sent before subscription confirmation.. wash/rinse/repeat)
> 
> Greetings,
> 
> Seeing PREEMPT_RT in ipipe source, I got curious, extracted 4.4.43, and
> wedged it into 4.4.54-rt, but there are a couple places that replace a
>  spinlock_t (not raw) with an ipipe_spinlock_t, which cause build woes
> for PREEMPT_RT.  I ifdefed those problematic spots back to spinlock_t
> for grins, and surprisingly, my x64_64 desktop box booted, and does a
> decent impersonation of a functional box.. which left me wondering
> whether there's a preparatory patch for PREEMPT_RT somewhere, or
> whether the PREEMPT_RT bits are WIP (or leftovers).

As Jan pointed out already, those reverts may well cause havoc when some
code attempts to traverse such critical sections from a co-kernel
context (aka "head stage"), since the purpose of the original change is
precisely to allow this, i.e. we have to switch the spinlock construct
from virtual IRQ disabling to real disabling.

FWIW, since commit 18aaf9db, Xenomai 3 is assuming that only raw
spinlocks may be converted to hard pipeline locks, which is only
partially the case for the current pipeline architecture though; however
this is fully enforced by the next one I'm working on (i.e. dovetail).

-- 
Philippe.