Re: [PATCH v5] introduce macro spin_event_timeout()

[Grant Likely <grant.likely@secretlab.ca>]

On Tue, Mar 10, 2009 at 6:24 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
>>
>> Alan did have one valid point though. =A0Determining how long to loop
>> for is architecture-specific. =A0Using jiffies is bad, because even one
>> jiffy is too long. =A0Adding a udelay() inside the loop means that it
>> only checks he condition every microsecond. =A0So the real solution is
>> to use keep looping until a certain amount of time has passed. =A0This
>> 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. =A0But Alan still needs
>> to be convinced. =A0I already posted a length rebuttal to his email, but
>> I haven't gotten a reply yet.
>>
> There are several aspects here:
>
> =A0- The amount of time to wait should be specified by the caller since
> it's generally going to come from HW specs
>
> =A0- The amount of time between the polls ... that could also be an
> argument to the macro, not sure there
>
> =A0- The precision of the actual wait calls... I vote for microseconds fo=
r
> 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.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.