On 05/04/2015 03:39 PM, Paul E. McKenney wrote: > On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote:
>> In case of the non-preemptible RCU, we could easily also >> increase current->rcu_read_lock_nesting at the same time >> we increase the preempt counter, and use that as the >> indicator to test whether the cpu is in an extended >> rcu quiescent state. That way there would be no extra >> overhead at syscall entry or exit at all. The trick >> would be getting the preempt count and the rcu read >> lock nesting count in the same cache line for each task. > > But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt > counter in production kernels. Even if there was, we have to sample this > on other CPUs, so the overhead of preempt_disable() and preempt_enable() > would be where kernel entry/exit is, so I expect that this would be a > net loss in overall performance. CONFIG_PREEMPT_RCU seems to be independent of CONFIG_PREEMPT. Not sure why, but they are :) >> In case of the preemptible RCU scheme, we would have to >> examine the per-task state (under the runqueue lock) >> to get the current task info of all CPUs, and in >> addition wait for the blkd_tasks list to empty out >> when doing a synchronize_rcu(). >> >> That does not appear to require special per-cpu >> counters; examining the per-cpu rdp and the lists >> inside it, with the rnp->lock held if doing any >> list manipulation, looks like it would be enough. >> >> However, the current code is a lot more complicated >> than that. Am I overlooking something obvious, Paul? >> Maybe something non-obvious? :) > > Ummm... The need to maintain memory ordering when sampling task > state from remote CPUs? > > Or am I completely confused about what you are suggesting? > > That said, are you chasing a real system-visible performance issue > that you tracked to RCU's dyntick-idle system? The goal is to reduce the syscall overhead of nohz_full. Part of the overhead is in the vtime updates, part of it is in the way RCU extended quiescent state is tracked. -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
