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
prev parent reply other threads:[~2017-09-21 18:03 UTC|newest]
Thread overview: 17+ 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:04 ` Alan Stern
2017-09-18 19:10 ` Mathieu Desnoyers
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-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-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]
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 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.