![]() | |||||||||||||
Messages in this thread |
Richard, I did a few experiments using the example (jiq, I changed jiffies to do_gettimeofday() ) from Linux Device Driver, 2nd version (p196). I have two machines m1 and m2. On m1, I run a timer queue (jiq) module. Then I download a big file from m1 to m2. The timings are different between before ftp and during ftp. ---------------------------------------- before ftp ---------------------------------------- time pid cpu command 420590 1 0 0 swapper 430580 1 0 0 swapper 440579 1 0 0 swapper 450579 1 0 0 swapper 460579 1 0 0 swapper 470579 1 0 0 swapper 480579 1 0 0 swapper 490579 1 0 0 swapper 500579 1 0 0 swapper ---------------------------------------- during ftp ---------------------------------------- time pid cpu command 370605 1524 0 in.ftpd 380645 0 0 swapper 390583 0 0 swapper 400667 0 0 swapper 410703 1524 0 in.ftpd 420679 0 0 swapper 430634 0 0 swapper 440624 0 0 swapper 450648 0 0 swapper It shows that timer queue is still not accurate. So the conclusion of " you're guaranteed that the queue will run at the next clock tick, thus eliminating latency caused by system load" is WRONG!!! What is your opinion? Xinwen Fu On Wed, 3 Jul 2002, Richard B. Johnson wrote: > On Wed, 3 Jul 2002, Xinwen - Fu wrote: > > > Hi, all, > > I'm curious that if a network card interrupt happens at the same > > time as the kernel timer expires, what will happen? > > > > It's said the kernel timer is guaranteed accurate. But if > > interrupts are not masked off, the network interrupt also should get > > response when a kernel timer expires. So I don't know who will preempt > > who. > > > > Thanks for information! > > > > Xinwen Fu > > The highest priority interrupt will get serviced first. It's the timer. > Interrupts are serviced in priority-order. Hardware "remembers" which > ones are pending so none are lost if some driver doesn't do something > stupid. > > Cheers, > Dick Johnson > > Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). > > Windows-2000/Professional isn't. > > - 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/ | ||||||||||||
| Last update: 2005-03-22 12:27 [from the cache] ©2003-2008 | |||||||||||||