On 04.05.2005 [11:44:56 -0600], 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.
If I understand your point correctly, I think this is achieved by
TIMERINTERVAL_BITS in my patch (not to claim my patch is function, but
conceptually). No matter what you actually request, the best you can do
is 2^TIMERINTERVAL_BITS nanoseconds, and usually worse because the
tick-rate and timerinterval length do not necessarily line up.
Thanks,
Nish
-
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]
