Re: 2.6.11 timeval_to_jiffies() wrong for ms resolution timers

[Lee Revell <rlrevell@joe-job.com>]

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/