On Tue, Aug 01, 2017 at 12:00:47PM +1000, Nicholas Piggin wrote: > Thanks for this, I'll take a look. This should be a good start as a stress > test, but I'd also be interested in some application. The reason being that > for example using runqueue locks may give reasonable maximum throughput > numbers, but could cause some latency or slowdown when it's used in more > realistic scenario.
Given this is an unprivileged interface we have to consider DoS and other such lovely things. And since we cannot use mm_cpumask() we're stuck with for_each_online_cpu(). Combined that means that using rq->lock is completely out of the question, some numbnut doing 'for (;;) sys_membarrier();' can completely wreck the system. Yes, it might work for 'normal' workloads, but the interference potential is just too big. I have the same problem with Paul's synchronize_rcu_expedited() patch, that is a machine wide IPI spray and will interfere with unrelated work.
