Re: Timer-Interrupts using Events - Tickless Kernel
Posted: Mon Jan 29, 2018 9:04 am
Hi,
Note: I haven't looked into CPUID.15H; but if it's supported you might be able to determine if the CPU is overclocked by comparing what CPUID reports to what you actually measured (without more research than I've done, I wouldn't assume that the information provided by CPUID.15H is actually correct).
If the local APIC timer doesn't work when the CPU is in a "deep sleep" state; then I'd be tempted to use HPET to wake the CPU up again. For example, if it takes 123 us for the CPU to reach full speed after being woken from "deep sleep", then I'd want HPET to wake the CPU up slightly more than 123 us before the CPU needs to handle its next timer event, so that I have just enough time to get CPU back to full speed and synchronise the local APIC timer before letting it continue handling its timer events like normal.
Cheers,
Brendan
During boot you can (e.g.) use the PIT or HPET to measure "10 ms" and see how much the TSC and the local APIC count changed in 10 ms; and figure out both TSC frequency and local APIC timer frequency from that.ShukantPal wrote:Is there any way to determine the speed of the APIC timer? Using CPUID.15H, we could easily get the TSC's nominal frequency. How do I get the processor's current frequency? Also, the manual states that if CPUID.15H is not supported then the APIC timer ticks at the bus frequency? How to determine the bus frequency? Is the bus-frequency same as "scalable bus frequency" or "FSB-frequency"?
Note: I haven't looked into CPUID.15H; but if it's supported you might be able to determine if the CPU is overclocked by comparing what CPUID reports to what you actually measured (without more research than I've done, I wouldn't assume that the information provided by CPUID.15H is actually correct).
Actually...ShukantPal wrote:Also, as you said that "APIC timer may not work in sleep states", then i could use the HPET for IRQs. But then HPET doesn't have to provide many comparators - so only one/two/three CPUs will be able to handle timer IRQs. Any mitigation? If so, I could rely on the TSC only for scheduler purposes (as it requires v. high precision)?
If the local APIC timer doesn't work when the CPU is in a "deep sleep" state; then I'd be tempted to use HPET to wake the CPU up again. For example, if it takes 123 us for the CPU to reach full speed after being woken from "deep sleep", then I'd want HPET to wake the CPU up slightly more than 123 us before the CPU needs to handle its next timer event, so that I have just enough time to get CPU back to full speed and synchronise the local APIC timer before letting it continue handling its timer events like normal.
Accuracy and precision are quite different. For example, if you add 1000000000 to a counter each second, then you can say that the counter has 1 nanosecond precision and 1 second accuracy. The main reason to use 1 nanosecond precision (in APIs, standards, etc) is that it's relatively future-proof - the accuracy can be better or worse (and can be different on different computers with different time sources) without breaking the API, and most software won't care.ShukantPal wrote:Also, most OSes can't guarantee nano-second precision for executing events, right (due to scheduling or not being able interrupt a higher-priority task)? Then how does TSC improve performance (totally naive question)?
Cheers,
Brendan