Chris Friesen wrote:
George Anzinger wrote:
The, I think, elegant solution to the timer storm problem is to not
restart the timer until the user picks up the prior expiration. This
dynamically adjusts the timer response to the amount of machine
available at the time.
The disadvantage is that you then lose accuracy since each timer
interval is increased by some random amount based on system scheduling.
What about some kind of ulimit-type thing to specify the minimum
recurring interval that can be specified? If root so specifies, you
could have 1usec interval timers and the system would hang. This is
conceptually no different than busy-looping in a SCHED_FIFO task.
The standard comes to the rescue here. The standard defines timer_getoverrun()
which returns the number of additional timeouts you _would_ have seen if you had
been fast enough.
I tried a limit thing. It is MUCH too fragile for the real world.
--
George Anzinger [email protected]
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]
