Messages in this thread | | | From | Andrew Hunter <> | Date | Thu, 27 Jul 2017 11:36:38 -0700 | Subject | Re: Udpated sys_membarrier() speedup patch, FYI |
| |
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.
| |