Announcement

Collapse
No announcement yet.

AMD P-State Preferred Core Handling Being Enabled For Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • headkaze
    replied
    Here's amd_pstate_prefcore PATCH V14 and will work with kernel 6.8.

    Changes from V13->V14:
    - cpufreq:
    - - fix build error without CONFIG_CPU_FREQ

    - ACPI: CPPC:
    Changes from V12->V13:
    - ACPI: CPPC:
    - - modify commit message.
    - - modify handle function of the notify(0x85).
    - cpufreq: amd-pstate:
    - - implement update_limits() callback function.
    - x86:
    - - pick up Acked-By flag added by Petkov.

    Changes from V11->V12:
    - all:
    - - pick up Reviewed-By flag added by Perry.
    - cpufreq: amd-pstate:
    - - rebase the latest linux-next and fixed conflicts.
    - - fixed the issue about cpudata without init in amd_pstate_update_highest_perf().

    Changes from V10->V11:
    - cpufreq: amd-pstate:
    - - according Perry's commnts, I replace the string with str_enabled_disable().

    Changes from V9->V10:
    - cpufreq: amd-pstate:
    - - add judgement for highest_perf. When it is less than 255, the
    preferred core feature is enabled. And it will set the priority.
    - - deleset "static u32 max_highest_perf" etc, because amd p-state
    perferred coe does not require specail process for hotpulg.

    Changes form V8->V9:
    - all:
    - - pick up Tested-By flag added by Oleksandr.
    - cpufreq: amd-pstate:
    - - pick up Review-By flag added by Wyes.
    - - ignore modification of bug.
    - - add a attribute of prefcore_ranking.
    - - modify data type conversion from u32 to int.
    - Documentation: amd-pstate:
    - - pick up Review-By flag added by Wyes.

    Changes form V7->V8:
    - all:
    - - pick up Review-By flag added by Mario and Ray.
    - cpufreq: amd-pstate:
    - - use hw_prefcore embeds into cpudata structure.
    - - delete preferred core init from cpu online/off.

    Changes form V6->V7:
    - x86:
    - - Modify kconfig about X86_AMD_PSTATE.
    - cpufreq: amd-pstate:
    - - modify incorrect comments about scheduler_work().
    - - convert highest_perf data type.
    - - modify preferred core init when cpu init and online.
    - ACPI: CPPC:
    - - modify link of CPPC highest performance.
    - cpufreq:
    - - modify link of CPPC highest performance changed.

    Changes form V5->V6:
    - cpufreq: amd-pstate:
    - - modify the wrong tag order.
    - - modify warning about hw_prefcore sysfs attribute.
    - - delete duplicate comments.
    - - modify the variable name cppc_highest_perf to prefcore_ranking.
    - - modify judgment conditions for setting highest_perf.
    - - modify sysfs attribute for CPPC highest perf to pr_debug message.
    - Documentation: amd-pstate:
    - - modify warning: title underline too short.

    Changes form V4->V5:
    - cpufreq: amd-pstate:
    - - modify sysfs attribute for CPPC highest perf.
    - - modify warning about comments
    - - rebase linux-next
    - cpufreq:
    - - Moidfy warning about function declarations.
    - Documentation: amd-pstate:
    - - align with ``amd-pstat``

    Changes form V3->V4:
    - Documentation: amd-pstate:
    - - Modify inappropriate descriptions.

    Changes form V2->V3:
    - x86:
    - - Modify kconfig and description.
    - cpufreq: amd-pstate:
    - - Add Co-developed-by tag in commit message.
    - cpufreq:
    - - Modify commit message.
    - Documentation: amd-pstate:
    - - Modify inappropriate descriptions.

    Changes form V1->V2:
    - ACPI: CPPC:
    - - Add reference link.
    - cpufreq:
    - - Moidfy link error.
    - cpufreq: amd-pstate:
    - - Init the priorities of all online CPUs
    - - Use a single variable to represent the status of preferred core.
    - Documentation:
    - - Default enabled preferred core.
    - Documentation: amd-pstate:
    - - Modify inappropriate descriptions.
    - - Default enabled preferred core.
    - - Use a single variable to represent the status of preferred core.​
    Attached Files

    Leave a comment:


  • headkaze
    replied
    Here's amd_pstate_prefcore PATCH V13 and will work with kernel 6.7.

    Changes from V12->V13:
    - ACPI: CPPC:
    - - modify commit message.
    - - modify handle function of the notify(0x85).
    - cpufreq: amd-pstate:
    - - implement update_limits() callback function.
    - x86:
    - - pick up Acked-By flag added by Petkov.

    Changes from V11->V12:
    - all:
    - - pick up Reviewed-By flag added by Perry.
    - cpufreq: amd-pstate:
    - - rebase the latest linux-next and fixed conflicts.
    - - fixed the issue about cpudata without init in amd_pstate_update_highest_perf().

    Changes from V10->V11:
    - cpufreq: amd-pstate:
    - - according Perry's commnts, I replace the string with str_enabled_disable().

    Changes from V9->V10:
    - cpufreq: amd-pstate:
    - - add judgement for highest_perf. When it is less than 255, the
    preferred core feature is enabled. And it will set the priority.
    - - deleset "static u32 max_highest_perf" etc, because amd p-state
    perferred coe does not require specail process for hotpulg.

    Changes form V8->V9:
    - all:
    - - pick up Tested-By flag added by Oleksandr.
    - cpufreq: amd-pstate:
    - - pick up Review-By flag added by Wyes.
    - - ignore modification of bug.
    - - add a attribute of prefcore_ranking.
    - - modify data type conversion from u32 to int.
    - Documentation: amd-pstate:
    - - pick up Review-By flag added by Wyes.

    Changes form V7->V8:
    - all:
    - - pick up Review-By flag added by Mario and Ray.
    - cpufreq: amd-pstate:
    - - use hw_prefcore embeds into cpudata structure.
    - - delete preferred core init from cpu online/off.

    Changes form V6->V7:
    - x86:
    - - Modify kconfig about X86_AMD_PSTATE.
    - cpufreq: amd-pstate:
    - - modify incorrect comments about scheduler_work().
    - - convert highest_perf data type.
    - - modify preferred core init when cpu init and online.
    - ACPI: CPPC:
    - - modify link of CPPC highest performance.
    - cpufreq:
    - - modify link of CPPC highest performance changed.

    Changes form V5->V6:
    - cpufreq: amd-pstate:
    - - modify the wrong tag order.
    - - modify warning about hw_prefcore sysfs attribute.
    - - delete duplicate comments.
    - - modify the variable name cppc_highest_perf to prefcore_ranking.
    - - modify judgment conditions for setting highest_perf.
    - - modify sysfs attribute for CPPC highest perf to pr_debug message.
    - Documentation: amd-pstate:
    - - modify warning: title underline too short.

    Changes form V4->V5:
    - cpufreq: amd-pstate:
    - - modify sysfs attribute for CPPC highest perf.
    - - modify warning about comments
    - - rebase linux-next
    - cpufreq:
    - - Moidfy warning about function declarations.
    - Documentation: amd-pstate:
    - - align with ``amd-pstat``

    Changes form V3->V4:
    - Documentation: amd-pstate:
    - - Modify inappropriate descriptions.

    Changes form V2->V3:
    - x86:
    - - Modify kconfig and description.
    - cpufreq: amd-pstate:
    - - Add Co-developed-by tag in commit message.
    - cpufreq:
    - - Modify commit message.
    - Documentation: amd-pstate:
    - - Modify inappropriate descriptions.

    Changes form V1->V2:
    - ACPI: CPPC:
    - - Add reference link.
    - cpufreq:
    - - Moidfy link error.
    - cpufreq: amd-pstate:
    - - Init the priorities of all online CPUs
    - - Use a single variable to represent the status of preferred core.
    - Documentation:
    - - Default enabled preferred core.
    - Documentation: amd-pstate:
    - - Modify inappropriate descriptions.
    - - Default enabled preferred core.
    - - Use a single variable to represent the status of preferred core.​
    Attached Files

    Leave a comment:


  • mozin
    replied
    Has anyone with 3000 series threadripper cpu enabled amd pstate? I have 3960X and no matter I have done, dmesg is still reporting "the _CPC object is not present in SBIOS or ACPI disabled". TRX40 platform was buggy for Linux since the launch and sadly AMD didnt fix any of them.

    Leave a comment:


  • headkaze
    replied
    "Preferred Core" patch is currently at V2 [0]. What’s new: not much functionally. It is turned on by default, no longer requiring Kernel command line. Changed status file name from "prefcore_state" to "prefcore". Hence, to check enabled or not at run time, use this from V2 onwards:

    ```
    $ cat /sys/devices/system/cpu/amd_pstate/prefcore
    enabled​
    ```

    Tested on kernel 6.6 and appears to be working so far.
    Attached Files

    Leave a comment:


  • Anux
    replied
    Originally posted by sobrus View Post
    Lowering temperature limit can in fact have positive effect on both efficiency and speed, even if it is couter intuitive.
    Maybe, I will try and verify with some benchmarking.

    Leave a comment:


  • sobrus
    replied
    Originally posted by Anux View Post
    There is a reason why those modern CPUs easily consume 300 W, every little voltage step has a quadratic influence in power consumption.
    There is also a problem with current leakage - the hotter silicon gets, the more power it requires due to current leakage (and it gets even more hot).
    Ryzen is fully aware of it, and will not boost high when it's hot.
    So wasting power and heat to get 100Mhz more, can limit boost potential and ability to stay at higher clocks longer.
    Lowering temperature limit can in fact have positive effect on both efficiency and speed, even if it is couter intuitive.

    Leave a comment:


  • Anux
    replied
    Originally posted by sobrus View Post
    I haven't heard about anything like that, but with temperature limit reached, your clocks should go up after few seconds as the fans ramp up and cool cpu more.
    And if a task has been completed before this moment, a few seconds with like 5% less performance should not matter much anyway.
    It's a little different for me, as long as I don't run prime95 stress on all cores for hours the cores rarely exceed 68 °C, the fan is fixed to another sensor (package?) and only ramps up after a few minutes of full load (700 RPM until 45 °C are exceeded). So I guess a temp limit is not needed here at all.

    I've artifically limited my cpu to 4.8Ghz, because it's getting very inefficient above 4.7Ghz. First CCD (the better one) can do 4,7Ghz with around 6-7W per core, but reaching 4.9Ghz already needs 12W (and it's undervolted!). So it is twice as much power for around 4-5% more speed.
    There is a reason why those modern CPUs easily consume 300 W, every little voltage step has a quadratic influence in power consumption.

    My 5700G used 15 W per core (single thread prime95) and after curve optimizer -20 I got down to 11 W but before it wouldn't reach max clocks (maybe 4,5 GHz) for longer than a few ms and now it stays at 4,6 GHz with just those 11 W. In those upper ranges 100 MHz differences are already ~ 50 % more power.

    Not sure if I want to deal with per core tuning, since the stability testing is just too much effort.

    Leave a comment:


  • sobrus
    replied
    I haven't heard about anything like that, but with temperature limit reached, your clocks should go up after few seconds as the fans ramp up and cool cpu more.
    And if a task has been completed before this moment, a few seconds with like 5% less performance should not matter much anyway.

    I've artifically limited my cpu to 4.8Ghz, because it's getting very inefficient above 4.7Ghz. First CCD (the better one) can do 4,7Ghz with around 6-7W per core, but reaching 4.9Ghz already needs 12W (and it's undervolted!). So it is twice as much power for around 4-5% more speed.

    Second CCD will need 10W above 4.7Ghz and is usually unable to reach 4.8Ghz in stress test.
    Last edited by sobrus; 21 August 2023, 07:07 AM.

    Leave a comment:


  • Anux
    replied
    Originally posted by sobrus View Post
    This is not true. Ryzen can hit 90C temperature limit easily by pushing 15W+ through few individual cores (15W+ per each core), long before hitting any of these limits.
    They will only work for all-core loads.
    Yep that's what I have noticed too.
    The correct way of managing thermals (other than undervolting) is actually setting a temperature limit.
    Is there a way to define long and short term temp limits? Because the temp limit essentially prevents reaching max turbo (longer than a few nano seconds).

    Leave a comment:


  • sobrus
    replied
    Originally posted by emansom View Post
    Again, look into PPT, EDC and TDC for better thermals. PBO curve offset is not the place.
    This is not true. Ryzen can hit 90C temperature limit easily by pushing 15W+ through few individual cores (15W+ per each core), long before hitting any of these limits.
    They will only work for all-core loads.

    The correct way of managing thermals (other than undervolting) is actually setting a temperature limit.
    This way the CPU will manage frequency and per-core wattage (both current and voltage) according to actual temperature, current leakage and available cooling capacity.
    Last edited by sobrus; 21 August 2023, 04:16 AM.

    Leave a comment:

Working...
X