<div dir="ltr"><div><div>Hi,<br><br></div>I had a query regarding calling synchronize_rcu and synchronize_sched in _cpu_down path :<br></div><div>Here is the snippet below :<br></div><div><br> /*<br> * By now we've cleared cpu_active_mask, wait for all preempt-disabled<br> * and RCU users of this state to go away such that all new such users<br> * will observe it.<br> *<br> * For CONFIG_PREEMPT we have preemptible RCU and its sync_rcu() might<br> * not imply sync_sched(), so explicitly call both.<br> *<br> * Do sync before park smpboot threads to take care the rcu boost case.<br> */<br>#ifdef CONFIG_PREEMPT<br> synchronize_sched();<br>#endif<br> synchronize_rcu();<br><br></div><div>My query is that :<br></div><div>During cpu_down path, we do migrate tasks in this CPU to another CPU <br></div><div><br> As per LWN article here - <a href="http://lwn.net/Articles/253651/" target="_blank">http://lwn.net/Articles/253651/</a> :<br><i><br>For example, suppose that a task calls <code>rcu_read_lock()</code> on
one CPU, is preempted, resumes on another CPU, and then calls
<code>rcu_read_unlock()</code>.
The first CPU's counter will then be +1 and the second CPU's counter
will be -1, however, they will still sum to zero.
Regardless of possible preemption, when the sum of the old counter
elements does go to zero, it is safe to move to the next grace-period
stage, as shown on the right-hand side of the above figure.
</i><br></div><div><br></div><div>From what i understand : Since we migrate the tasks to another CPU, the read side critical sections should get completed from other CPU on which this task is going to run.<br>Therefore why call synchronize_rcu()/synchronize_sched() and wait in the cpu_down path while there is no write operations happening here in this code?<br><br></div><div>Thanks and regards,<br></div><div>Vignesh Radhakrishnan<br></div><div><br></div><div><br></div><br clear="all"><div><div><div><div><div><br><br></div></div></div></div></div></div>