Re: Udpated sys_membarrier() speedup patch, FYI

From	Andrew Hunter <ahh@google.com>
Newsgroups	linux.kernel
Subject	Re: Udpated sys_membarrier() speedup patch, FYI
Date	2017-07-27 20:40 +0200
Message-ID	<u7VRw-195-21@gated-at.bofh.it> (permalink)
References	<u7Vya-12j-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, Jul 27, 2017 at 11:12 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> Hello!
> But my main question is whether the throttling shown below is acceptable
> for your use cases, namely only one expedited sys_membarrier() permitted
> per scheduling-clock period (1 millisecond on many platforms), with any
> excess being silently converted to non-expedited form.

Google doesn't use sys_membarrier (that I know of...), but we do use
RSEQ fences, which implements membarrier + a little extra to interrupt
RSEQ critical sections (via IPI--smp_call_function_many.)  One
important optimization here is that we only throw IPIs to cpus running
the same mm as current (or a subset if requested by userspace), as
this is sufficient for the API guarantees we provide. I suspect a
similar optimization would largely mitigate DOS concerns, no? I don't
know if there are use cases not covered. To answer your question:
throttling these (or our equivalents) would be fine in terms of
userspace throughput. We haven't noticed performance problems
requiring such an intervention, however.

Furthermore: I wince a bit at the silent downgrade; I'd almost prefer
-EAGAIN or -EBUSY. In particular, again for RSEQ fence, the downgrade
simply wouldn't work; rcu_sched_qs() gets called at many points that
aren't sufficiently quiescent for RSEQ (in particular, when userspace
code is running!)  This is solvable, but worth thinking about.

Thread

Udpated sys_membarrier() speedup patch, FYI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-27 20:20 +0200
  Re: Udpated sys_membarrier() speedup patch, FYI Andrew Hunter <ahh@google.com> - 2017-07-27 20:40 +0200
    Re: Udpated sys_membarrier() speedup patch, FYI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-27 21:10 +0200
      Re: Udpated sys_membarrier() speedup patch, FYI Andrew Hunter <ahh@google.com> - 2017-07-28 19:40 +0200
        Re: Udpated sys_membarrier() speedup patch, FYI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-28 20:20 +0200
  Re: Udpated sys_membarrier() speedup patch, FYI Avi Kivity <avi@scylladb.com> - 2017-07-27 21:30 +0200
    Re: Udpated sys_membarrier() speedup patch, FYI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-27 21:50 +0200
      Re: Udpated sys_membarrier() speedup patch, FYI Avi Kivity <avi@scylladb.com> - 2017-07-27 22:10 +0200
        Re: Udpated sys_membarrier() speedup patch, FYI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-27 22:40 +0200
          Re: Udpated sys_membarrier() speedup patch, FYI Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-07-27 23:00 +0200
            Re: Udpated sys_membarrier() speedup patch, FYI Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-07-27 23:10 +0200
              Re: Udpated sys_membarrier() speedup patch, FYI Avi Kivity <avi@scylladb.com> - 2017-07-31 08:10 +0200
                Re: Udpated sys_membarrier() speedup patch, FYI Peter Zijlstra <peterz@infradead.org> - 2017-07-31 10:40 +0200
                Re: Udpated sys_membarrier() speedup patch, FYI Avi Kivity <avi@scylladb.com> - 2017-07-31 11:00 +0200
      Re: Udpated sys_membarrier() speedup patch, FYI Andrew Hunter <ahh@google.com> - 2017-07-28 19:20 +0200
        Re: Udpated sys_membarrier() speedup patch, FYI Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-07-28 19:30 +0200
        Re: Udpated sys_membarrier() speedup patch, FYI "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-28 19:40 +0200
          Re: Udpated sys_membarrier() speedup patch, FYI Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2017-07-28 19:50 +0200

csiph-web