Messages in this thread |  | | | Subject | Re: 2.6.11 timeval_to_jiffies() wrong for ms resolution timers | | From | Lee Revell <> | | Date | Thu, 26 May 2005 15:32:36 -0400 |
| |
On Thu, 2005-05-26 at 12:24 -0700, George Anzinger wrote: > Lee Revell wrote: > > On Thu, 2005-05-26 at 14:10 -0400, Richard B. Johnson wrote: > > > >>The time for a sleeping (waiting) task to get the CPU is much > >>greater than the jitter. Once in the ISR, some wake-up call > >>is "scheduled" and the interrupt returns. A CPU hog may have > >>been using the CPU when the interrupt occurred. It will continue > >>to use the CPU until its time-slot (quantum) has expired. This > >>could be a whole millisecond if HZ is 1000, 10 milliseconds if > >>100. It's only then that your sleeping task gets awakened > >>by the interrupting event. > >> > >>So, accurate waking up is not guaranteed on any multi-user, > >>multitasking system because you don't know what a user has > >>been doing with the CPU. On a dedicated machine, one can > >>have tasks that are most always sleeping or waiting for > >>I/O so, the latency can come way down. However, signaling > >>a task, based upon some time will never be very accurate > >>anywhere. > > > > > > Not quite, if your sleeping task has higher priority than the CPU hog it > > will preempt the CPU hog immediately on return from the interrupt. > > Unless you've disabled preemption of course, which would be stupid in > > this case. > > And even then the task would need to be in the kernel and would be preempted > when it exits the kernel. >
Right, and normally the sleeping task would be woken up even if it had the same static priority as the CPU hog as the scheduler should favor event driven proceses.
Lee
- 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/
|  |