Bill Holler wrote: > Eric Saxe wrote: >> Hi Bill, >> >> Bill Holler wrote: >> >>> Is there any other speedup we can do to reduce HPET scheduling? >>> The current implementation only programs the HPET for the >>> next lAPIC interrupt that would fire. The HPET is not accessed >>> when later lAPIC interrupt are "scheduled" onto the HPET until. >>> >> Just to make sure I understand... >> What happens in the current implementation when multiple CPUs enter a >> deep c-state. Im guessing that the earliest request wakeup winds up >> being what the HPET is programmed for, and then in the context of >> that interrupt you re-program the HPET to interrupt to expire the >> later request? >> > > Yes. The scenario you described is correct. > > Additionally the interrupt service routine interrupts all CPUs that > have expired at the time the ISR is running. It is possible for > multiple CPUs to expire at the same time, or at least by the time > the HPET's ISR runs. > > poke_cpu() is used to send the IPI because of its low overhead.
We could experiment with more aggressive expirations. In other words, the HPET ISR could also interrupt CPUs which will expire in the very near future. The trade off is a little less deep C-state on idle CPUs for less HPET interrupts. We could make this "aggressive window" slide (increase/decrease) with HPET interrupt frequency. We could also slide the promotion/ demotion logic for enterring deep C-states with load. Just thinking out loud. :-) The experiments have not been run to see if we need to do this. Regards, Bill
