From: "Paul E. McKenney" <paulmck@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, tglx@linutronix.de,
linux-kernel@vger.kernel.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
frederic@kernel.org, Will Deacon <will@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
npiggin@gmail.com
Subject: Re: [PATCH 0/6] sched: TTWU, IPI, and assorted stuff
Date: Fri, 19 Jun 2020 11:46:44 -0700 [thread overview]
Message-ID: <20200619184644.GN2723@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <20200619181128.GC576888@hirez.programming.kicks-ass.net>
On Fri, Jun 19, 2020 at 08:11:28PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 19, 2020 at 10:48:02AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 19, 2020 at 10:20:47AM -0700, Paul E. McKenney wrote:
>
> > > > @@ -2615,7 +2617,8 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> > > > * let the waker make forward progress. This is safe because IRQs are
> > > > * disabled and the IPI will deliver after on_cpu is cleared.
> > > > */
> > > > - if (READ_ONCE(p->on_cpu) && ttwu_queue_wakelist(p, cpu, wake_flags | WF_ON_RQ))
> > > > + if (smp_load_acquire(&p->on_cpu) &&
> >
> > Given the x86 memory model, this only protects against the compiler
> > reordering accesses in ttwu_queue_wakelist() against the fetch of
> > p->on_cpu, correct?
>
> Yes.
>
> > Don't get me wrong, I do see some potential compiler misorderings,
> > including with cpu_rq(cpu)->nr_running. Just curious.
>
> Given this is arch independent code, I'd better write generic code, and
> there I really think this wants to be acquire. I'll also try and write a
> comment for next time.
I completely understand and agree. Just trying to work out why my
systems hit this more than an order of magnitude more often than do
yours. Compiler version might be important? As noted on IRC, I am
using gcc 8.2.1.
Thanx, Paul
next prev parent reply other threads:[~2020-06-19 18:46 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 12:56 [PATCH 0/6] sched: TTWU, IPI, and assorted stuff Peter Zijlstra
2020-06-15 12:56 ` [PATCH 1/6] sched: Fix ttwu_queue_cond() Peter Zijlstra
2020-06-15 13:34 ` Peter Zijlstra
2020-06-15 16:45 ` Paul E. McKenney
2020-06-15 22:58 ` Paul E. McKenney
2020-06-22 9:11 ` Mel Gorman
2020-06-22 9:41 ` Peter Zijlstra
2020-06-15 12:56 ` [PATCH 2/6] sched: Verify some SMP assumptions Peter Zijlstra
2020-06-15 12:56 ` [PATCH 3/6] sched: s/WF_ON_RQ/WQ_ON_CPU/ Peter Zijlstra
2020-06-22 9:13 ` Mel Gorman
2020-06-15 12:56 ` [PATCH 4/6] smp, irq_work: Continue smp_call_function*() and irq_work*() integration Peter Zijlstra
2020-06-15 12:56 ` [PATCH 5/6] irq_work: Cleanup Peter Zijlstra
2020-06-16 15:16 ` Petr Mladek
2020-06-15 12:57 ` [PATCH 6/6] smp: Cleanup smp_call_function*() Peter Zijlstra
2020-06-15 14:34 ` Jens Axboe
2020-06-15 16:04 ` Daniel Thompson
2020-06-17 8:23 ` Christoph Hellwig
2020-06-17 9:00 ` Peter Zijlstra
2020-06-17 11:04 ` Peter Zijlstra
2020-06-18 6:51 ` Christoph Hellwig
2020-06-18 16:25 ` Peter Zijlstra
2020-06-15 16:23 ` [PATCH 0/6] sched: TTWU, IPI, and assorted stuff Paul E. McKenney
2020-06-15 16:40 ` Peter Zijlstra
2020-06-15 17:21 ` Paul E. McKenney
2020-06-15 19:11 ` Peter Zijlstra
2020-06-15 19:55 ` Paul E. McKenney
2020-06-16 16:31 ` Paul E. McKenney
2020-06-16 17:04 ` Peter Zijlstra
2020-06-16 17:17 ` Peter Zijlstra
2020-06-16 17:53 ` Paul E. McKenney
2020-06-19 13:44 ` Peter Zijlstra
2020-06-19 17:20 ` Paul E. McKenney
2020-06-19 17:48 ` Paul E. McKenney
2020-06-19 18:11 ` Peter Zijlstra
2020-06-19 18:46 ` Paul E. McKenney [this message]
2020-06-20 18:46 ` Paul E. McKenney
2020-06-16 17:51 ` 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=20200619184644.GN2723@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).