All of lore.kernel.org
 help / color / mirror / Atom feed
From: joe.korty@concurrent-rt.com
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Julia Cartwright <julia@ni.com>, <bigeasy@linutronix.de>,
	<mingo@redhat.com>, <tglx@linutronix.de>,
	<linux-rt-users@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING
Date: Mon, 26 Mar 2018 11:54:51 -0400	[thread overview]
Message-ID: <20180326155451.GA16545@zipoli.concurrent-rt.com> (raw)
In-Reply-To: <20180326113515.720e7fb3@gandalf.local.home>

Oh well.  Makes me wonder why might_sleep is testing for
!TASK_RUNNABLE though.

Thanks for the correction,
Joe


On Mon, Mar 26, 2018 at 11:35:15AM -0400, Steven Rostedt wrote:
> On Fri, 23 Mar 2018 13:21:31 -0400
> joe.korty@concurrent-rt.com wrote:
> 
> > My understanding is, in standard Linux and in rt, setting
> > task state to anything other than TASK_RUNNING in of itself
> > blocks preemption.
> 
> That is clearly false. The only thing that blocks preemption with a
> CONFIG_PREEMPT kernel is preempt_disable() and local_irq*() disabling.
> 
> (Note spin_locks call preempt_disable in non RT).
> 
> Otherwise, nothing will stop preemption.
> 
> >  A preemption is not really needed here
> > as it is expected that there is a schedule() written in that
> > will shortly be executed.  And if a 'involuntary schedule'
> > (ie, preemption) were allowed to occur between the task
> > state set and the schedule(), that would change the task
> > state back to TASK_RUNNING, which would cause the schedule
> > to NOP.  Thus we risk not having paused long enough here
> > for the condition we were waiting for to become true.
> 
> That is also incorrect. As Julia mentioned, a preemption keeps the
> state of the task.

  reply	other threads:[~2018-03-26 15:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-23 15:09 [PATCH RT] Defer migrate_enable migration while task state != TASK_RUNNING joe.korty
2018-03-23 16:59 ` Julia Cartwright
2018-03-23 17:21   ` joe.korty
2018-03-23 17:42     ` Julia Cartwright
2018-03-26 15:35     ` Steven Rostedt
2018-03-26 15:54       ` joe.korty [this message]
2018-03-26 15:59         ` Steven Rostedt

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=20180326155451.GA16545@zipoli.concurrent-rt.com \
    --to=joe.korty@concurrent-rt.com \
    --cc=bigeasy@linutronix.de \
    --cc=julia@ni.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.