[PATCH v5] introduce macro spin_event_timeout()

[Grant Likely]

On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt
<benh at 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.