From: Steven Rostedt <rostedt@goodmis.org>
To: paulmck@us.ibm.com
Cc: shemminger@osdl.org, dipankar@in.ibm.com, mingo@elte.hu,
linux-kernel@vger.kernel.org
Subject: Re: PREEMPT/PREEMPT_RT question
Date: Tue, 12 Jul 2005 16:04:17 -0400 [thread overview]
Message-ID: <1121198657.3548.11.camel@localhost.localdomain> (raw)
In-Reply-To: <20050712192832.GB1323@us.ibm.com>
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 ;-)
> > 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.
-- Steve
next prev parent reply other threads:[~2005-07-12 20:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-12 16:30 PREEMPT/PREEMPT_RT question Paul E. McKenney
2005-07-12 17:05 ` Steven Rostedt
2005-07-12 19:28 ` Paul E. McKenney
2005-07-12 20:04 ` Steven Rostedt [this message]
2005-07-12 21:34 ` Paul E. McKenney
2005-07-12 23:47 ` Steven Rostedt
2005-07-13 1:46 ` Paul E. McKenney
2005-07-13 3:54 ` Steven Rostedt
2005-07-13 15:41 ` Paul E. McKenney
2005-07-12 19:26 ` Ingo Molnar
2005-07-12 21:04 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1121198657.3548.11.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@us.ibm.com \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox