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

[Zwane Mwaikambo]

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.

Thanks,
	Zwane "who usually doesn't condone interface abuse" Mwaikambo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/