On Wed, Dec 21, 2011 at 1:44 AM, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote: > On 12/21/2011 10:40 AM, Colin Cross wrote: > >>> this smells fundamentally racey to me; you can get an interrupt one >>> cycle after you think you're done, but before the last guy enters WFI... >>> >>> how do you solve that issue ? >> >> All the cpus have interrupts off when they increment the counter, so >> they cannot receive an interrupt. If an interrupt is pending on one >> of those cpus, it will be handled later when WFI aborts due to the >> pending interrupt. > > ... but this leads to cases where you're aborting before other cpus are > entering..... so your "last guy in" doesn't really work, since while cpu > 0 thinks it's the last guy, cpu 1 is already on the way out/out > already... (heck it might already be going back to sleep if your idle > code can run fast, like in the size of a cache miss) Once a cpu has incremented the counter, it has no way out unless either 1: another cpu (that hasn't incremented the counter yet) receives an interrupt, aborts idle, and clears its idle flag or 2: all cpus enter the ready counter, and call the cpuidle driver's enter function. In your example, cpu 1 has incremented the counter, so it cannot be on the way out unless cpu 0 aborts (in which case it will not increment the counter, and the counter will never be equal to the number of cpus), or unless cpu 0 turns off its interrupts and incrementes the counter (in which case neither cpu can return until after the cpuidle driver's enter function has been called on all cpus). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
