On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote: >> >> Alan did have one valid point though. Determining how long to loop >> for is architecture-specific. Using jiffies is bad, because even one >> jiffy is too long. Adding a udelay() inside the loop means that it >> only checks he condition every microsecond. So the real solution is >> to use keep looping until a certain amount of time has passed. This >> means using an architecture-specific timebase register. > >> Now we can create a generic version of the function that uses jiffies, >> and then arch-specific versions where possible. But Alan still needs >> to be convinced. I already posted a length rebuttal to his email, but >> I haven't gotten a reply yet. >> > There are several aspects here: > > - The amount of time to wait should be specified by the caller since > it's generally going to come from HW specs > > - The amount of time between the polls ... that could also be an > argument to the macro, not sure there > > - The precision of the actual wait calls... I vote for microseconds for > everything and udelay. The arch will do its best.
No, not udelay. Or any delay for that matter. If spinning on a condition, then there is no advantage to burning cycles with a udelay(). Those cycles may as well be used to keep testing the condition so the loop can be exited faster. a udelay() would only serve to always make the busywait longer. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev