public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 19:47:15 -0400	[thread overview]
Message-ID: <1121212035.3548.34.camel@localhost.localdomain> (raw)
In-Reply-To: <20050712213426.GD1323@us.ibm.com>

On Tue, 2005-07-12 at 14:34 -0700, Paul E. McKenney wrote:

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

I was being a little harsh in my statements.  I didn't really mind the
LL and SC but a true atomic inc would have been nice.  I actually had to
port Linux to a MIPS board once that didn't have the LL or SC, and that
was even more painful.

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

If you are talking about scheduler_tick, then yes, it is called by the
timer interrupt which is a SA_NODELAY interrupt.  If you don't want to
get interrupted by the timer interrupt, then you will need to disable
interrupts for both. Since currently, the timer interrupt is the only
true hard interrupt in the PREEMPT_RT and that may not change.

-- Steve



  reply	other threads:[~2005-07-12 23:48 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
2005-07-12 21:34       ` Paul E. McKenney
2005-07-12 23:47         ` Steven Rostedt [this message]
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=1121212035.3548.34.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