Re: Fw: [RFC] Strange code in cpu_idle()

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Mon, Dec 06, 2004 at 02:38:33AM -0700, Zwane Mwaikambo wrote:
> Hi,
> 	The original intent to go with synchronize_kernel and RCU 
> protection was for simplicity's sake, as the alternative implementations 
> at the time looked like major overkill. Now in defense of this method, 
> when entering the idle thread and placing the processor in a holding state 
> (hlt) and an RCU grace period is begun, the processor in the holding state 
> will be unaware of the new RCU grace period until it exits the idle loop 
> callback (pm_idle) anyway, so the rcu_read will block the other processors 
> from making RCU grace period completion as much as the processor holding 
> state. This is true of all current pm_idle callbacks on i386, x86_64 and 
> ia64 with the exception of APM (but i'll conveniently ignore that for now 
> ;). When we do take an interrupt to exit the processor holding state and 
> run through rcu_check_callbacks we will notice that we are in a hard 
> interrupt and will defer marking of the processsor as quiescent. By that 
> point we will have exited the idle thread callback therefore making it 
> safe to use synchronize_kernel to protect removal of the callback.

I am not going to claim to thoroughly understand the power-management
code, but do have an additional question.

What happens if the processor became aware of a new grace period just
before entering pm_idle?  I could imagine this code simply refusing
to power down the processor if there was a pending grace period, but
I don't see any sign of this.  I could also imagine somehow deferring
interrupts until pm_idle exits.  I don't see anything that looks like
it does this, but don't claim to be any sort of power-management
expert.

						Thanx, Paul