Re: [PATCH] PREEMPT_RT_FULL: ARM context switch needs IRQs enabled

From: Catalin Marinas
Date: Fri Dec 16 2011 - 06:43:42 EST


On Fri, Dec 16, 2011 at 11:13:19AM +0000, Catalin Marinas wrote:
> On Fri, Dec 16, 2011 at 09:54:32AM +0000, Peter Zijlstra wrote:
> > On Thu, 2011-12-15 at 19:20 -0800, Frank Rowand wrote:
> > > ARMv6 and later have VIPT caches and the TLBs are tagged with an ASID
> > > (application specific ID). The number of ASIDs is limited to 256 and
> > > the allocation algorithm requires IPIs when all the ASIDs have been
> > > used. The IPIs require interrupts enabled during context switch for
> > > deadlock avoidance.
> > >
> > > The RT patch mm-protect-activate-switch-mm.patch disables irqs around
> > > activate_mm() and switch_mm(), which are the portion of the ARMv6
> > > context switch that require interrupts enabled.
> > >
> > > The solution for the ARMv6 processors could be to _not_ disable irqs.
> > > A more conservative solution is to provide the same environment that
> > > the scheduler provides, that is preempt_disable(). This is more
> > > resilient for possible future changes to the ARM context switch code
> > > that is not aware of the RT patches.
> > >
> > > This patch will conflict slightly with Catalin's patch set to remove
> > > __ARCH_WANT_INTERRUPTS_ON_CTXSW, when that is accepted:
> > >
> > > http://lkml.indiana.edu/hypermail/linux/kernel/1111.3/01893.html
> > >
> > > When Catalin's patch set is accepted, this RT patch will need to reverse
> > > the change in patch 6 to arch/arm/include/asm/system.h:
> >
> >
> > We could just merge Catalin's stuff in -rt to give it a test ride and
> > see if anything horrible happens.. :-)
>
> Russell agreed for me to push this to -next (in case -rt uses that, not
> sure) to get a bit more exposure. Otherwise testing the patches in -rt
> would really help spotting bugs.
>
> But we need to sort out the dangling switch_mm() calls (without a
> corresponding post-switch hook call) that I mentioned in my reply to
> Frank.

And that's what I meant (running some tests on a Versatile Express SMP
system, they seem alright so far):