From: Will Deacon <will.deacon@arm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Boqun Feng <boqun.feng@gmail.com>,
Andrew Hunter <ahh@google.com>,
Maged Michael <maged.michael@gmail.com>,
gromer@google.com, Avi Kivity <avi@scylladb.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Dave Watson <davejwatson@fb.com>,
Andy Lutomirski <luto@kernel.org>, Hans Boehm <hboehm@google.com>
Subject: Re: [RFC PATCH v3] membarrier: provide core serialization
Date: Fri, 1 Sep 2017 17:25:47 +0100 [thread overview]
Message-ID: <20170901162547.GA20313@arm.com> (raw)
In-Reply-To: <20170901161007.2661-1-mathieu.desnoyers@efficios.com>
On Fri, Sep 01, 2017 at 12:10:07PM -0400, Mathieu Desnoyers wrote:
> Add a new MEMBARRIER_FLAG_SYNC_CORE flag to the membarrier
> system call. It allows membarrier to issue core serializing barriers in
> addition to memory barriers on target threads whenever a membarrier
> command is performed.
>
> It is relevant for reclaim of JIT code, which requires to issue core
> serializing barriers on all threads running on behalf of a process
> after ensuring the old code is not visible anymore, before re-using
> memory for new code.
>
> The new MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED used with
> MEMBARRIER_FLAG_SYNC_CORE flag registers the current process as
> requiring core serialization. It may block. It can be used to ensure
> MEMBARRIER_CMD_PRIVATE_EXPEDITED never blocks, even the first time it is
> invoked by a process with the MEMBARRIER_FLAG_SYNC_CORE flag.
>
> * Scheduler Overhead Benchmarks
>
> Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
> Linux v4.13-rc6
>
> Inter-thread scheduling
> taskset 01 ./perf bench sched pipe -T
>
> Avg. usecs/op Std.Dev. usecs/op
> Before this change: 2.55 0.10
> With this change: 2.49 0.08
> SYNC_CORE processes: 2.70 0.10
>
> Inter-process scheduling
> taskset 01 ./perf bench sched pipe
>
> Before this change: 2.93 0.13
> With this change: 2.93 0.13
> SYNC_CORE processes: 3.20 0.06
>
> Changes since v2:
> - Rename MEMBARRIER_CMD_REGISTER_SYNC_CORE to
> MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED,
I'm still not convinced that this registration step is needed (at least
for arm, power and x86), but my previous comments were ignored.
> - Introduce the "MEMBARRIER_FLAG_SYNC_CORE" flag.
> - Introduce CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE, only implemented by
> x86 32/64 initially.
> - Introduce arch_membarrier_user_icache_flush, a no-op on x86 32/64,
> which can be implemented on architectures with incoherent data and
> instruction caches. It is associated with
> CONFIG_ARCH_HAS_MEMBARRIER_USER_ICACHE_FLUSH.
Given that MEMBARRIER_FLAG_SYNC_CORE is about flushing the internal CPU
pipeline (iiuc), could we rename this so that it doesn't mention the
I-cache, please? I-cache flushing is a very different operation on most
architectures I'm aware of, and on arm64 it's even available to userspace
(and broadcast in hardware to other cores).
Will
next prev parent reply other threads:[~2017-09-01 16:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-01 16:10 [RFC PATCH v3] membarrier: provide core serialization Mathieu Desnoyers
2017-09-01 16:25 ` Will Deacon [this message]
2017-09-01 17:00 ` Mathieu Desnoyers
2017-09-01 17:10 ` Will Deacon
2017-09-01 18:45 ` Mathieu Desnoyers
[not found] ` <CAMOCf+jjy2hjqdmrqFuVvnS8p-i+3Z3ZLubk4ymnRfsdT_F8PA@mail.gmail.com>
2017-09-18 17:01 ` Will Deacon
[not found] ` <CAMOCf+gqMFmw9WCYqE_dXG3J+K=qBVT3Pv=z6CyrbppU6Y5qig@mail.gmail.com>
2017-10-06 20:57 ` Mathieu Desnoyers
2017-10-06 21:08 ` Peter Zijlstra
2017-10-09 8:32 ` Will Deacon
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=20170901162547.GA20313@arm.com \
--to=will.deacon@arm.com \
--cc=ahh@google.com \
--cc=avi@scylladb.com \
--cc=benh@kernel.crashing.org \
--cc=boqun.feng@gmail.com \
--cc=davejwatson@fb.com \
--cc=gromer@google.com \
--cc=hboehm@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=maged.michael@gmail.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mpe@ellerman.id.au \
--cc=paulmck@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--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.