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
next prev parent 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