Hi BIll, Bill.Holler wrote:
> Hi Aubrey, > > How will idle cpu wakeup be done? cpu_acpi_idle() introduces three > potential cpu idles states. A cpu currently calls > disp_enq_thread() when > it wants to wakeup an idle cpu when it enqueued a thread on the > idle cpu's dispatcher queue. Solaris's disp_enq_thread() function > currently uses just one wakeup method because there was only one > possible idle state. I believe a cpu will have to send an > inter processor > interrupt to wakeup a cpu in the C2 or C3 idle states? An IPI is used > to wakeup an idle cpu when the "halt" idle loop is used, but a low > overhead memory write is used to wakeup an idle cpu from the > MWAIT idle loop. Do we want to go back to using the HLT instruction > in the C1 idle loop to allow the wakeup mechanism to be the > same for all > idle states? We found an MWAIT idle loop to have the same power > savings and better performance on Intel processors. > cpudrv_pm_init_module() does not change the cpu wakeup mechanism > when it sets idle_cpu to cpu_acpi_idle. I noticed this issue and yeah, you are right, mwait is better than halt. But from ACPI spec, if the register(which OSPM reads to place the processor in the corresponding C state) address space id is returned the SystemIO type, We'll use the register ioport to place the processor into deeper c-state. That means we have to wakeup cpu by sending interrupt. Different wakeup mechanism for different idle state will be better for me, as long as it's doable. > > Eric and I have been talking about a policy to determine which idle > state to use. We know decision input will include: > 1. time until next cyclic fires on this cpu. > 2. dispatcher hint. The power-aware dispatcher will try to > move threads > off whole cpu chips based on system idleness. > 3. User specified policy. > 4. C-state round trip latency. > cpu_acpi_idle() could call an idle policy function to determine with > C state to attempt. > deeper C-state needs TSC be fixed. What's the status of it and HPET timer? Thanks, -Aubrey
