On Thu, Sep 16, 2021 at 07:19:21PM +0800, Rafael J. Wysocki wrote:

On Thu, Sep 16, 2021 at 12:09 PM Huang Rui [off-list ref] wrote:

quoted

On Mon, Sep 13, 2021 at 07:56:32PM +0800, Peter Zijlstra wrote:

quoted

On Mon, Sep 13, 2021 at 06:54:58PM +0800, Huang Rui wrote:

quoted

On Mon, Sep 13, 2021 at 04:56:24PM +0800, Peter Zijlstra wrote:

quoted

quoted

quoted

1) Full MSR Support
If current hardware has the full MSR support, we register "pstate_funcs"
callback functions to implement the MSR operations to control the clocks.

What's the WRMSR cost for those? I've not really kept track of the MSR
costs on AMD platforms, but on Intel it has (luckily) been coming down
quite a bit.

Good to know this, I didn't have a chance to give a check. May I know how
did you test this latency? But MSR is new hardware design for this
solution, as designer mentioned, the WRMSR is low-latency register model is
faster than ACPI AML code interpreter.

quoted

quoted

2) Shared Memory Support
If current hardware doesn't have the full MSR support, that means it only
provides share memory support. We will leverage APIs in cppc_acpi libs with
"cppc_funcs" to implement the target function for the frequency control.

Right, the mailbox thing. How is the performance of this vs MSR accesses?

I will give a check. If you have a existing test method that can be used, I
can check it quickly.

Oh, I was mostly wondering if using the mailbox as MMIO would be faster
than an MSR, but you've already answered that above. Also:

quoted

quoted

quoted

1. As mentioned above, amd-pstate driver can implement
fast_switch/adjust_perf function with full MSR operations that have better
performance for schedutil and other governors.

Why couldn't the existing cppc-cpufreq grow this?

Because fast_switch can adjust the frequency directly in the interrupt
context, if we use the acpi cppc handling with shared memory solution, it
will have a deadlock. So fast switch needs the control with registers
directly like acpi-cpufreq and intel-pstate.

Aah, I see, you're only doing fast_switch support when you have MSRs.
That was totally non-obvious.. :/

Yes, I should have written a comment to there. :-)
Will update this in V2.

quoted

But then amd_pstate_adjust_perf() could just direct call the pstate
methods and we don't need that indirection *at*all*, right?

Hmm, yes, if we use amd_pstate_adjust_perf here, we won't need to call
amd_pstate_fast_switch. I saw intel_pstate had adjust_perf and fast_switch
at the same time, would you mind to let me know how to distinguish these
two use scenario on intel processors?

The ->fast_switch() callback is for the use cases in which
->adjust_perf() cannot be installed, that is basically systems without
HWP enabled.

OK, I see. Thanks to clarify this.

Thanks,
Ray