Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Fri, 30 Apr 1999 01:21:48 +0100 (BST) | Subject | Re: Re: Clock |
| |
Hi,
On Tue, 27 Apr 1999 14:03:06 +0100 (GMT), Riley Williams <rhw@bigfoot.com> said:
>> It was being looked at. The 2.2 kernels should now be OK when >> the jiffies counter wraps.
> I havenae seen any comments re this being definately fixed, and > haven't had reason to change HZ on my systems, so I will plead > ignorance of the current status.
It's not necessarily 100% fixed, but at least we couldn't find any more broken places. The newer kernels have a good set of time comparison routines which avoid the wrap problems entirely.
> As you appear to be better informed than me, can you answer a few > questions on this subject please?
> 1. There is presumably a maximum rate to which HZ can be set that > is dictated by the hardware. What is it?
It depends on the clock rate, but there are other issues: increasing HZ too much adds a lot of overhead to the kernel, as you end up taking more frequent scheduling interrupts --- which costs CPU time --- and rescheduling processes more often --- which costs memory bandwidth as you refill the TLB and memory caches.
As far as hardware is concerned, the figure of 800KHz sticks in my memory as the maximum granularity of the timer used for the scheduler, but I could well be wrong there.
> 2. There is presumably also a separate maximum rate to which HZ > can be set before the timer interrupt routine starts taking > too large a proportion of the inter-timer-interrupt intervals. > This will of course be dependant on the processor and its > speed, but is there any sort of formula to determine what this > will be for any given processor?
Not really, because the exact cost of each tick depends so much on just what the workload is.
> 3. Am I right in thinking that the jiffies counter is a 32-bit > counter? If so, would I be right in thinking that the maximum > interval that can be measured is (2^32-1.0)/HZ seconds ?
The maximum interval the kernel can delay for is 2^31/HZ seconds, not 2^32, because we need to distinguish between past and future. However, device and networking drivers only use jiffies for relatively short-term timeouts: the longer-term timeouts are all measured in seconds (sometimes allowing fractional seconds too, as in the struct timeval), so they won't time out for a few years yet. (But we still have problems in the year 2038.)
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |