Daniel Walker wrote:
On Thu, 9 Jun 2005, George Anzinger wrote:
So, in short, I don't see the point to the suggested change. If the kernel is
late, it is best to let it catch up as fast as it can by looping here. The only
counter argument that makes sense to me it that in this case we are starving
other softirqd driven tasks, but that should, if any thing, lighten the timer
load and let this complete faster.
I'm mainly concerned because that loop never breaks . It seems like there
could be a condition when the loop never stops. For instance , a very
accurate timer interrupt, and timers that continually reset themselves.
As I recall, it is not possible to put a timer in the list for the current time.
It will be put in the next tick slot or, with HRT, be passed to the hrt code.
The only case this might fail is if a kernel hrt user restarts his timer for
"now" or prior to "now". This is bad and hard to correct. The posix-timers
code does not restart timers until the signal is delivered and then from the
user thread, not the softirq context.
Did I miss something here?
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
