public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Will Deacon <will.deacon@arm.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Michael Ellerman <mpe@ellerman.id.au>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Dave Watson <davejwatson@fb.com>,
	maged michael <maged.michael@gmail.com>
Subject: Re: Rough notes from sys_membarrier() lightning BoF
Date: Thu, 21 Sep 2017 18:03:06 +0000 (UTC)	[thread overview]
Message-ID: <182479244.15905.1506016986660.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20170921131501.abv4ul2cnpef72j2@hirez.programming.kicks-ass.net>

----- On Sep 21, 2017, at 9:15 AM, Peter Zijlstra peterz@infradead.org wrote:

> On Wed, Sep 20, 2017 at 06:13:50PM +0000, Mathieu Desnoyers wrote:
>> My proposed RFC for private expedited membarrier enforces that all
>> architectures perform the registration step. Using the "PRIVATE_EXPEDITED"
>> command without prior process registration returns an error on all
>> architectures. The goal here is to make all architectures behave in the
>> same way, and it allows us to rely on process registration to deal
>> with future arch-specific optimizations.
>> 
>> Adding the "core_sync" behavior could then be done for the next kernel
>> merge window. I'm currently foreseeing two possible ABI approaches to
>> expose it:
>> 
>> Approach 1:
>> 
>> Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE and
>> MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_SYNC_CORE commands. This
>> allows us to return their availability through MEMBARRIER_CMD_QUERY.
>> 
>> Approach 2:
>> 
>> Add a "MEMBARRIER_FLAG_SYNC_CORE" as flag parameter. It could be set
>> when issuing both MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED and
>> MEMBARRIER_CMD_PRIVATE_EXPEDITED, thus ensuring core serializing
>> behavior. Querying whether core serialization is supported could
>> be done by issuing the MEMBARRIER_CMD_QUERY command with the
>> MEMBARRIER_FLAG_SYNC_CORE flag set.
>> 
>> Any other ideas ? Any approach seems better ?
> 
> So we really need another FLAG for that? AFAICT the current
> PRIVATE_EXPEDITED is already sufficient for the cross modifying code,
> since the IPI triggers an exception return on all currently running CPUs
> and the future running CPUs will have the return to userspace doing the
> exception return.
> 
> The only issue is Andy fudging our x86 ret-to-userspace to not use IRET,
> which we can fix by forcing it into the slowpath (that needs to exist
> anyway) using that new TIF flag.

I agree that x86, as it stands today, would provide core serialization
with the private expedited membarrier command. And we can deal with
future optimization of ret-to-userspace using the TIF flag set on
registration.

I'm wondering whether all architectures guarantee core serialization
on return from interrupt triggered by the IPI, and on ret-to-userspace ?

Thanks,

Mathieu

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

  reply	other threads:[~2017-09-21 18:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-17 22:36 Rough notes from sys_membarrier() lightning BoF Paul E. McKenney
2017-09-18 19:04 ` Alan Stern
2017-09-18 19:10   ` Mathieu Desnoyers
2017-09-18 19:29   ` Paul E. McKenney
2017-09-18 19:29     ` Paul E. McKenney
2017-09-18 19:37     ` Mathieu Desnoyers
2017-09-18 20:34       ` Paul E. McKenney
2017-09-18 20:34         ` Paul E. McKenney
2017-09-20 16:02 ` Andy Lutomirski
2017-09-20 16:02   ` Andy Lutomirski
2017-09-20 18:13   ` Mathieu Desnoyers
2017-09-20 18:18     ` Andy Lutomirski
2017-09-20 19:57       ` Mathieu Desnoyers
2017-09-21 13:09     ` Peter Zijlstra
2017-09-21 17:23       ` James Bottomley
2017-09-21 17:23         ` James Bottomley
2017-09-22  9:33         ` Peter Zijlstra
2017-09-22  5:08       ` Michael Ellerman
2017-09-21 13:15     ` Peter Zijlstra
2017-09-21 18:03       ` Mathieu Desnoyers [this message]
2017-09-21 18:03         ` 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=182479244.15905.1506016986660.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=davejwatson@fb.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=maged.michael@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=will.deacon@arm.com \
    /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