Messages in this thread | | | Date | Tue, 20 Jan 2004 01:59:41 -0800 | From | George Anzinger <> | Subject | Re: timing code in 2.6.1 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |