|
@@ -722,13 +722,19 @@ static void sync_rcu_exp_handler(void *info)
|
|
* synchronize_rcu_expedited - Brute-force RCU grace period
|
|
* synchronize_rcu_expedited - Brute-force RCU grace period
|
|
*
|
|
*
|
|
* Wait for an RCU-preempt grace period, but expedite it. The basic
|
|
* Wait for an RCU-preempt grace period, but expedite it. The basic
|
|
- * idea is to invoke synchronize_sched_expedited() to push all the tasks to
|
|
|
|
- * the ->blkd_tasks lists and wait for this list to drain. This consumes
|
|
|
|
- * significant time on all CPUs and is unfriendly to real-time workloads,
|
|
|
|
- * so is thus not recommended for any sort of common-case code.
|
|
|
|
- * In fact, if you are using synchronize_rcu_expedited() in a loop,
|
|
|
|
- * please restructure your code to batch your updates, and then Use a
|
|
|
|
- * single synchronize_rcu() instead.
|
|
|
|
|
|
+ * idea is to IPI all non-idle non-nohz online CPUs. The IPI handler
|
|
|
|
+ * checks whether the CPU is in an RCU-preempt critical section, and
|
|
|
|
+ * if so, it sets a flag that causes the outermost rcu_read_unlock()
|
|
|
|
+ * to report the quiescent state. On the other hand, if the CPU is
|
|
|
|
+ * not in an RCU read-side critical section, the IPI handler reports
|
|
|
|
+ * the quiescent state immediately.
|
|
|
|
+ *
|
|
|
|
+ * Although this is a greate improvement over previous expedited
|
|
|
|
+ * implementations, it is still unfriendly to real-time workloads, so is
|
|
|
|
+ * thus not recommended for any sort of common-case code. In fact, if
|
|
|
|
+ * you are using synchronize_rcu_expedited() in a loop, please restructure
|
|
|
|
+ * your code to batch your updates, and then Use a single synchronize_rcu()
|
|
|
|
+ * instead.
|
|
*/
|
|
*/
|
|
void synchronize_rcu_expedited(void)
|
|
void synchronize_rcu_expedited(void)
|
|
{
|
|
{
|