Li, Aubrey wrote: > 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. > Yes, a wakeup mechanism for different idle states should be doable. A wakeup_cpu_acpi() function could be the same as cpu_wakeup() except it would call a poke_cpu_acpi() function instead of poke_cpu(). poke_cpu_acpi() would check the target cpu's idle state (C1HALT, C1MWAIT, C2, C3) and perform the appropriate wakeup mechanism: IPI or memory write. targetcpu->cpu_idle_type should be good enough to decide wakeup mechanism.
There is no chance of a "missed wakeup" if the idle cpu wakes up and then enters a different idle state in the window between the idle state check and the wakeup because the CPU_IN_SET(->mc_haltset) check is done after the dispatch queue was updated. The idle cpu would see its work in the case where it wakes up before the enqueueing cpu wakes it. >> 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? > We need systems to test TSC fixup code. There are several strategies we want to test. 1. re-sync a cpu's TSC with a master using x-call, 2. keep per-thread or per-cpu "last TST" to fixup when a thread reads an older TST (yuck). The HPET timer could be used to re-initialize TSC when all cpus have returned from a deep C-state. I am starting work on this now. I will start testing by injecting TSC clobbers during C1 idle wakeup on a Core 2 Duo until new hardware arrives. Prototype HPET code is working. It maps the HPET and provides a function to read the HPET timer. I will put this back into the tesla hpet gate asap. The code to enable HPET generated interrupts is not there. Additionally the cyclic subsystem uses the local APIC for interrupt generation. The APIC is powered off on penryn during deeper C-states. Work needs to be done to move the cyclic timeouts to another source such as the HPET or another cpu. Regards, Bill > Thanks, > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
