Li, Aubrey wrote:
> Bill.Holler wrote:
>
>
>> Li, Aubrey wrote:
>>
>>> Bill.Holler wrote:
>>>
>>>
>>>
>>>> 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?
>>>>
>>>>
>>> Maybe you have to explain what exactly needs to be restored in the
>>> idle thread.
>>>
>>>
>> For example the APIC and TSC may need to be restored if they were
>> powered off in a deep idle state.
>>
>
> I think this exactly could be done in idle_cpu->cpu_acpi_idle().
>
> cpu_acpi_idle()
> {
> switch(cstate_type) {
> case CPU_ACPI_C2/C3:
> tsc_base = read_TSC();
> apic_base = read_APIC_TIMER();
> start = read_HPET();
> /* TSC and ACPI timer lost */
> enter_deeper_cstate();
> end = read_HPET();
> re-initialize_TSC() { TSC= tsc_base + end - start }
> re-initialize_APIC() { APIC = apic_base + end - start }
> }
>
> Does this make sense?
>
>
Yes. This is close to what we plan to do. :-)
>>>> Does Intel guaranty MWAIT eax ecx states will not map to deeper
>>>> ACPI c-states than the eax value?
>>>>
>>>>
>>>>
>>> MWAIT Extension Register (ECX)
>>> Bit0 - Treat Interrupt as break-event, even when interrupts are
>>> disabled Bit31: 1 - Reserved
>>>
>>> MWAIT Hints Register (EAX)
>>> Bit3 : 0 - Sub C-state within a C-state, indicated by bits [7:4]
>>> Bit7 : 4 - Target C-state* Bit31 : 8 - Reserved
>>>
>>> Maybe I didn't catch your point, but can the register definitions
>>> answer your question?
>>>
>>>
>>>
>> Hi Aubrey,
>>
>> Are we guarantied the processor will not enter a deeper idle state
>> than specified by the MWAIT command? I am confused because
>> I thought the hardware could go into a deeper idle state than
>> specified by the MWAIT instruction target c-state and sub c-state.
>> For example if MWAIT target c-state 1 does not power off the APIC,
>> are we guarantied the processor will not enter ACPI c-state where
>> the TSC and APIC may be powered off?
>>
>>
>
> if monitor/mwait is supported, we use MWAIT to enter deeper cstate.
> otherwise we'll read io port to enter deeper cstate. so mwait is not the
> only code path to power off TSC and APIC.
>
> But both of the two ways are wrapped in cpu_acpi_cx(), let's take a look
> again at the above piece of pseudo code.
>
> cpu_acpi_idle()
> {
> switch(cstate_type) {
> case CPU_ACPI_C2/C3:
> tsc_base = read_TSC();
> apic_base = read_APIC_TIMER();
> start = read_HPET();
> /* TSC and ACPI timer lost */
> enter_deeper_cstate(); <== cpu_acpi_cx();
> end = read_HPET();
> re-initialize_TSC() { TSC= tsc_base + end - start }
> re-initialize_APIC() { APIC = apic_base + end - start }
> }
>
> here, TSC and APIC issue will be dealt for both mwait and reading io
> port ways
> to enter deeper c-state.
>
> Please correct me if I'm wrong, ;-)
>
Are there systems where CPU_ACPI_C2 does not reset the TSC
and APIC state on existing hardware? If so we would like to avoid
needlessly restoring state.
Thank you,
Bill
> Thanks,
> -Aubrey
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>
