Lines Matching refs:invocation

193 that waits, directly or indirectly, on completion of an invocation of
506    CPUs during that invocation, then each of the CPUs in that group is
1221 of ``synchronize_rcu()``, thus amortizing the per-invocation overhead
1356 | be correct, given that the invocation of the callback and the freeing |
1413 In theory, delaying grace-period completion and callback invocation is
1431 to ensure timely completion of grace periods and timely invocation of
1464 invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has
1476    invocation at the expense of degrading realtime response.
1481 RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward
1485 both ``rcu_nocbs`` CPUs and high ``call_rcu()`` invocation rates, then
1757 This delay in callback invocation is due to the fact that RCU does not
1873 invocation of ``call_rcu()``, then invoke ``rcu_barrier()``. In theory,
1988 reorder a ``get_user()`` invocation into an RCU read-side critical section.
2257 invocations can safely be deferred. Deferring invocation could
2405 invocation will be delayed until the time of the
2549 by default), and if a ``synchronize_srcu()`` invocation ends this idle
2550 period, that invocation will be automatically expedited.
2663 invocation.