Just got too deep in my inbox.. :-) I will do another try here, and followup with phonecall to close the loop
Cheers, ashok raj - Open Source Technology Center >-----Original Message----- >From: tesla-dev-bounces at opensolaris.org [mailto:tesla-dev-bounces at opensolaris.org] On Behalf Of Li, >Aubrey >Sent: Wednesday, January 23, 2008 10:06 PM >To: Bill.Holler at Sun.COM >Cc: tesla-dev at opensolaris.org >Subject: Re: [tesla-dev] C-state driver draft update > >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 >_______________________________________________ >tesla-dev mailing list >tesla-dev at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/tesla-dev
