Re: timing code in 2.6.1

[George Anzinger <george@mvista.com>]

Richard B. Johnson wrote:
> On Fri, 16 Jan 2004, Andrew Morton wrote:
> 
> 
>>"Richard B. Johnson" <root@chaos.analogic.com> wrote:
>>
>>>
>>>Some drivers are being re-written for 2.6++. The following
>>>construct seems to work for "waiting for an event" in
>>>the kernel modules.
>>>
>>>        // No locks are being held
>>>        tim = jiffies + EVENT_TIMEOUT;
>>>        while(!event() && time_before(jiffies, tim))
>>>            schedule_timeout(0);
>>>
>>>Is there anything wrong?
>>
>>This is not a good thing to be doing.  You should add this task to a
>>waitqueue and then sleep.  Make the code which causes event() to come true
>>deliver a wake_up to that waitqueue.  There are many examples of this in
>>the kernel.
>>
> 
> 
> Huh? The code that causes "event()" needs to get the CPU occasionally
> to check for the event. The hardware doesn't produce an interrupt
> upon that event.

THAT is where the hardware designer went wrong.  An interrupt is really the best 
way for hardware to notify the cpu of an event.  Details may then be read from 
hardware registers, if needed.

The request of a 0 timeout is really asking for a timeout on the last jiffie.  I 
suspect that relying on this to actually not happen until the next jiffie is NOT 
a good thing.  I am not aware of any spec that says that is what it should do 
and I am aware of timer patchs that will run the timer immeadiatly.  A request 
for 1 jiffie will do the same thing in the current kernel AND under that patch. 
  That thing being, by the way, is to wait for the next jiffie which will be any 
time from ~0 to 1 jiffie.
> 
Lots of words, which did not explain why an interrupt was not used to signal the 
event, deleted :)
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml