OSDev.org :: View topic - Timer-Interrupts using Events

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"?

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)?

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)?

Author:	Brendan [ Mon Jan 29, 2018 9:04 am ]
Post subject:	Re: Timer-Interrupts using Events - Tickless Kernel
Hi, 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"? 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. 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). 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)? Actually... 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. 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)? 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. Cheers, Brendan

OSDev.org https://forum.osdev.org/

Timer-Interrupts using Events - Tickless Kernel https://forum.osdev.org/viewtopic.php?f=15&t=32706	Page 2 of 2

Page 2 of 2	All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/