Messages in this thread | | | Date | Wed, 24 Nov 2010 22:50:08 +0100 | Subject | Re: [PATCH 1/2] rcu: Don't chase unnecessary quiescent states after extended grace periods | From | Frederic Weisbecker <> |
| |
2010/11/24 Paul E. McKenney <paulmck@linux.vnet.ibm.com>: > On Wed, Nov 24, 2010 at 09:45:08PM +0100, Frederic Weisbecker wrote: >> 2010/11/24 Paul E. McKenney <paulmck@linux.vnet.ibm.com>: >> > I take it back. I queued the following -- your code, but updated >> > comment and commit message. Please let me know if I missed anything. >> > >> > Thanx, Paul >> > >> > ------------------------------------------------------------------------ >> > >> > commit 1d9d947bb882371a0877ba05207a0b996dcb38ee >> > Author: Frederic Weisbecker <fweisbec@gmail.com> >> > Date: Wed Nov 24 01:31:12 2010 +0100 >> > >> > rcu: Don't chase unnecessary quiescent states after extended grace periods >> > >> > When a CPU is in an extended quiescent state, including offline and >> > dyntick-idle mode, other CPUs will detect the extended quiescent state >> > and respond to the the current grace period on that CPU's behalf. >> > However, the locking design prevents those other CPUs from updating >> > the first CPU's rcu_data state. >> > >> > Therefore, when this CPU exits its extended quiescent state, it must >> > update its rcu_data state. Because such a CPU will usually check for >> > the completion of a prior grace period before checking for the start of a >> > new grace period, the rcu_data ->completed field will be updated before >> > the rcu_data ->gpnum field. This means that if RCU is currently idle, >> > the CPU will usually enter __note_new_gpnum() with ->completed set to >> > the current grace-period number, but with ->gpnum set to some long-ago >> > grace period number. Unfortunately, __note_new_gpnum() will then insist >> > that the current CPU needlessly check for a new quiescent state. This >> > checking can result in this CPU needlessly taking several scheduling-clock >> > interrupts. >> >> >> So I'm all ok for the commit and the comments updated. But just a doubt about >> the about sentence. >> >> The effect seems more that there will be one extra softirq. But not an >> extra tick >> because before sleeping, the CPU will check rcu_needs_cpu() which >> doesn't check for >> the need of noting a quiescent state, IIRC... >> >> And I think the softirq will be only raised on the next tick. >> >> Hm? > > Good point! This paragraph now reads: > > Therefore, when this CPU exits its extended quiescent state, > it must update its rcu_data state. Because such a CPU will > usually check for the completion of a prior grace period > before checking for the start of a new grace period, the > rcu_data ->completed field will be updated before the rcu_data > ->gpnum field. This means that if RCU is currently idle, the > CPU will usually enter __note_new_gpnum() with ->completed set > to the current grace-period number, but with ->gpnum set to some > long-ago grace period number. Unfortunately, __note_new_gpnum() > will then insist that the current CPU needlessly check for a new > quiescent state. This checking can result in this CPU needlessly > taking an additional softirq for unnecessary RCU processing. > > Fair enough?
Perfect! :)
Thanks a lot! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |