Li, Aubrey wrote: > Bill.Holler wrote: > > >> Li, Aubrey wrote: >> >>> the function to place processor into deeper c-state is added. >>> >>> I discussed with Bill about how to enter deeper c-state. >>> The ACPI documentation uses reading ACPI register address to enter, >>> while Intel Processor programming guides indicate MWAIT is prefered. >>> >>> We know, to wake up an idle CPU, mwait just needs monitor memory >>> write. But "halt" and ACPI reading IO port need an IPI. Obviously, >>> mwait has the better performance. >>> >>> So, here, I didn't see any advantage to follow ACPI on the >>> mwait-supported processors. The logic breaking ACPI rule in the >>> committed code is as follows: >>> >>> if (mwait is supported) >>> use monitor/mwait to enter deep c-state >>> else >>> reading IO port from ACPI >>> >>> Of course this logic depends on the info reading from ACPI objects. >>> So disp_enq_thread doesn't need to be changed. >>> >>> Any objects/thoughts? >>> >>> >> Do we have a mechanism to map ACPI c-states to/from MWAIT >> c-states? >> > > No, we don't. > > The Solaris idle threads will have to restore more state > >> when returning from deeper ACPI c-states such as C3. The idle >> threads will need to be aware of the MWAIT<->ACPI c-state mapping. >> >> > > I think restoring job should be done in idle_cpu->cpu_acpi_idle, not out > of idle_cpu > in idle thread. So mapping may not be necessary. > But correct me if I'm wrong, ;-) > > I do not understand how idle_cpu->cpu_acpi_idle or cpu_acpi_idle_mwait will know what it needs to restore?
Does Intel guaranty MWAIT eax ecx states will not map to deeper ACPI c-states than the eax value? thank you, Bill > Thanks, > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
