Messages in this thread | | | Date | Mon, 04 May 2015 15:59:02 -0400 | From | Rik van Riel <> | Subject | Re: question about RCU dynticks_nesting |
| |
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
| |