Timur Tabi wrote:
On Wed, Mar 11, 2009 at 2:22 PM, Scott Wood <scottw...@freescale.com> wrote:
I was under the impression that we were only talking about timeouts, and
that the common case was significantly shorter than that.
I think one of the concerns that Alan Cox raised is that the existence
of this macro would encourage people to spin for long durations.
Yes, and I've already stated my response to that line of thinking. I
just don't see anyone who would have done something better than a spin
loop changing their mind because doing a spin loop becomes a little
easier -- the spin loop is *already* easier than the alternatives.
What if another variant were added that did msleep between iterations,
for longer expected completion times? Or if we want to be really fancy,
combine them into one function that starts with small udelays, then
switches to msleep of progressively larger intervals up to some maximum?
If it's atomic because preemption was disabled, yes -- but even a rare
extended spin in such a context would be bad for hard realtime. If
interrupts are disabled, or the code is executing from a timer interrupt (or
possibly other interrupts depending on the hardware and its priority
scheme), no.
So in that case, I can't rely on jiffies.
Or you can say that atomic context is outside the scope of this macro.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
