Re: PREEMPT/PREEMPT_RT question

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Tue, Jul 12, 2005 at 04:04:17PM -0400, Steven Rostedt wrote:
> On Tue, 2005-07-12 at 12:28 -0700, Paul E. McKenney wrote:
> > > 
> > > So is there a difference on UP between x.counter++ and atomic_inc(&x)?
> > 
> > On x86, you are right.  The full list of architectures that are atomic
> > only in SMP are i386 (as you noted), parisc, sparc, and x86_64.
> > 
> > The architectures that appear to always be atomic are: alpha, ia64, m32r
> > (but unfamiliar with this one), mips, ppc, ppc64, s390 (I think...),
> > and sparc64.  Most of these architectures need to disable interrupts
> > to provide "universal" atomic_inc() semantics in UP kernels, due to
> > their RISC-style atomic instructions.  
> > 
> > The following architectures avoid the issue entirely by refusing to
> > support SMP: arm, arm26, cris, frv, h8300, m68k, m68knommu, sh, sh64,
> > and v850.  Many of them disable interrupts in their atomic_inc()
> > implementations.
> > 
> > The advantage of smp_atomic_inc() is that architectures could dispense
> > with interrupt disabling.  The disadvantage is that it is yet another
> > contribution to Linux's combinatorial explosion of primitives.
> > 
> > For the moment, I will grit my teeth and keep atomic_inc() and atomic_dec().
> > 
> > Other thoughts?
> 
> How did I know that you would mention mips and the like :-)
> 
> Yeah, mips has the crazy Load Linked and Store Conditional crap, so it
> is a little more complex than the simple add one.  And I think PPC does
> too, although it has been a while since I've used them.  And older mips
> don't have the LL SC command so the only option is to turn off
> interrupts (of course those that don't have the LL and SC are not SMP
> compatible).  So, I will admit that having a smp_atomic_inc might be
> nice. I was just being a narrow minded x86 hacker ;-)

I am sure that LL/SC seemed like a good idea at the time.  ;-)

To be fair, LL/SC does allow allow some things to be done more easily
than with cmpxchg, since it allows you to tell that the value changed
even if it later changed back.  Helps with some linked-list operations.

> > > Yep interrupts are threads in CONFIG_PREEMPT_RT.  I guess you could also
> > > just use local_irq_save with spin_lock, since now local_irq_save no
> > > longer disables interrupts in PREEMPT_RT.
> > 
> > By this you mean the following?
> > 
> > 	local_irq_save(flags);
> > 	_raw_spin_lock(&mylock);
> > 
> > 	/* critical section */
> > 
> > 	_raw_spin_unlock(&mylock);
> > 	local_irq_restore(flags);
> 
> Yeah, that on PREEMP_RT would not turn off interrupts but just stops
> preemption. This is fine as long as the mylock is not used in any
> SA_NODELAY interrupt.

Cool!  Is the scheduling-clock interrupt an SA_NODELAY interrupt?

							Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/