All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Boqun Feng <boqun.feng@gmail.com>, Andrew Hunter <ahh@google.com>,
	maged michael <maged.michael@gmail.com>,
	gromer <gromer@google.com>, Avi Kivity <avi@scylladb.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [RFC PATCH v2] membarrier: expedited private command
Date: Fri, 28 Jul 2017 15:38:15 +0000 (UTC)	[thread overview]
Message-ID: <2118431661.29566.1501256295573.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20170728115702.5vgnvwhmbbmyrxbf@hirez.programming.kicks-ass.net>

----- On Jul 28, 2017, at 7:57 AM, Peter Zijlstra peterz@infradead.org wrote:

> On Fri, Jul 28, 2017 at 10:55:32AM +0200, Peter Zijlstra wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index e9785f7aed75..33f34a201255 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2641,8 +2641,18 @@ static struct rq *finish_task_switch(struct task_struct
>> *prev)
>>  	finish_arch_post_lock_switch();
>>  
>>  	fire_sched_in_preempt_notifiers(current);
>> +
>> +	/*
>> +	 * For CONFIG_MEMBARRIER we need a full memory barrier after the
>> +	 * rq->curr assignment. Not all architectures have one in either
>> +	 * switch_to() or switch_mm() so we use (and complement) the one
>> +	 * implied by mmdrop()'s atomic_dec_and_test().
>> +	 */
>>  	if (mm)
>>  		mmdrop(mm);
>> +	else if (IS_ENABLED(CONFIG_MEMBARRIER))
>> +		smp_mb();
>> +
>>  	if (unlikely(prev_state == TASK_DEAD)) {
>>  		if (prev->sched_class->task_dead)
>>  			prev->sched_class->task_dead(prev);
>> 
>> 
> 
>> a whole bunch of architectures don't in fact need this extra barrier at all.
> 
> In fact, I'm fairly sure its only PPC.
> 
> Because only ARM64 and PPC actually implement ACQUIRE/RELEASE with
> anything other than smp_mb() (for now, Risc-V is in this same boat and
> MIPS could be if they ever sort out their fancy barriers).
> 
> TSO archs use a regular STORE for RELEASE, but all their atomics imply a
> smp_mb() and there are enough around to make one happen (typically
> mm_cpumask updates).
> 
> Everybody else, aside from ARM64 and PPC must use smp_mb() for
> ACQUIRE/RELEASE.
> 
> ARM64 has a super duper barrier in switch_to().
> 
> Which only leaves PPC stranded.. but the 'good' news is that mpe says
> they'll probably need a barrier in switch_mm() in any case.

As I pointed out in my other email, I plan to do this:

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2636,6 +2636,11 @@ static struct rq *finish_task_switch(struct task_struct *prev)
        vtime_task_switch(prev);
        perf_event_task_sched_in(prev, current);
        finish_lock_switch(rq, prev);
+       /*
+        * The membarrier system call requires a full memory barrier
+        * after storing to rq->curr, before going back to user-space.
+        */
+       smp_mb__after_unlock_lock();
        finish_arch_post_lock_switch();
 
        fire_sched_in_preempt_notifiers(current);

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2017-07-28 15:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-27 21:13 [RFC PATCH v2] membarrier: expedited private command Mathieu Desnoyers
2017-07-27 22:13 ` Paul E. McKenney
2017-07-27 22:41   ` Mathieu Desnoyers
2017-07-27 22:57     ` Paul E. McKenney
2017-07-28  8:55 ` Peter Zijlstra
2017-07-28 11:10   ` Peter Zijlstra
2017-07-28 11:57   ` Peter Zijlstra
2017-07-28 15:38     ` Mathieu Desnoyers [this message]
2017-07-28 16:46       ` Peter Zijlstra
2017-07-28 17:06         ` Mathieu Desnoyers
2017-07-29  1:58           ` Nicholas Piggin
2017-07-29  9:23             ` Peter Zijlstra
2017-07-29  9:45               ` Nicholas Piggin
2017-07-29  9:48                 ` Nicholas Piggin
2017-07-29 10:51                   ` Peter Zijlstra
2017-07-31 19:31             ` Mathieu Desnoyers
2017-07-31 13:20     ` Michael Ellerman
2017-07-31 13:36       ` Peter Zijlstra
2017-08-01  0:35       ` Nicholas Piggin
2017-08-01  1:33         ` Mathieu Desnoyers
2017-08-01  2:00           ` Nicholas Piggin
2017-08-01  8:12             ` Peter Zijlstra
2017-08-01  9:57               ` Nicholas Piggin
2017-08-01 10:22                 ` Peter Zijlstra
2017-08-01 10:32                   ` Avi Kivity
2017-08-01 10:46                     ` Peter Zijlstra
2017-08-01 10:39                   ` Nicholas Piggin
2017-08-01 11:00                     ` Peter Zijlstra
2017-08-01 11:54                       ` Nicholas Piggin
2017-08-01 13:23                   ` Paul E. McKenney
2017-08-01 14:16                     ` Peter Zijlstra
2017-08-01 23:32                       ` Paul E. McKenney
2017-08-02  0:45                         ` Nicholas Piggin
2017-07-28 15:36   ` Mathieu Desnoyers

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=2118431661.29566.1501256295573.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=ahh@google.com \
    --cc=avi@scylladb.com \
    --cc=benh@kernel.crashing.org \
    --cc=boqun.feng@gmail.com \
    --cc=gromer@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maged.michael@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.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 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.