(NOTE: This is a summary of my investigation that happened internally, created as a kernel bug at request of @jskarvad, the TuneD maintainer.)

1. Please describe the problem:

When the intel_pstate driver is used, setting the CPU governor to 'powersave' and adjusting energy performance bias/preference to performance results in significantly faster performance than using the actual 'performance' governor.

Originally, the issue was thought to be with the default throughput-performance profile in TuneD. Additional testing and investigation revealed a possibly unexpected/unwanted behavior of the intel_pstate driver.

My own benchmarking was done by running the compilation of the mainline Linux kernel with the default config (make defconfig) three times (N=3) on Thinkpad T14 Gen5, Intel Core Ultra 7 165U on two TuneD profiles:

First one (P1) is the default throughput-performance profile, where the intel_pstate governor is set to performance.
Second one (P2) is a _modified_ throughput-performance profile, where the cpu.governor setting is changed to 'powersave'.

Each compilation was timed, and this is the result I've got (each run in seconds):

P1: 320.96, 335.10, 334.36 (average: 330.14)
P2: 257.89, 258.30, 257.94 (average: 258.04)

P2, on average, appears to be around 28% faster than P1.

Investigation of this issue has been triggered by the following performance benchmark, where Fedora scored lowest: https://www.phoronix.com/review/fedora-pantherlake-thermald-tuned

Author of the article noted that once TuneD was switched for the older power-profiles-deamon, performance was improved significantly. In case of the intel_pstate driver, power-profiles-deamon appears to _always_ set the governor to powersave, regardless of the selected profile. This is the only meaningful difference between the performance profiles of TuneD and power-profiles-daemon.

Kernel documentation for the intel_pstate driver (https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html) states that, with HWP, the 'performance' governor ignores the EPP and EBP information from sysfs and instead sets both to 0, which is supposed to set the P-state selection logic to focus entirely on performance. The 'powersave' governor, on the other hand, takes the EPP and EBP knob information from sysfs.

I believe that there might be a bug in how the EBP and EPP knobs are set when the 'performance' governor is set, as the benchmarks above (both the article's and my own) show that 'powersave' with manually set EBP and EPP appears to be faster than 'performance'.

2. What is the Version-Release number of the kernel:

kernel-7.1.5-100.fc43.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Unknown.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

I prepared a copy of the throughput-performance TuneD profile with a different CPU governor:
```
cp -r /usr/lib/tuned/profiles/throughput-performance /etc/tuned/profiles/throughput-performance-powersave
sed -i 's/governor=performance/governor=powersave/' /etc/tuned/profiles/throughput-performance-powersave/tuned.conf
```

In the directory with the unpacked mainline kernel source code, I ran the following script:
```
#!/bin/sh

test_run() {
    NAME="$1"
    ccache -C
    make mrproper
    make defconfig
    time -p make -j12 2>$NAME.time.txt
}

N=3

test_run "dummy" # Mostly to heat up the CPU to account for possible throttling.
tuned-adm profile throughput-performance 
for i in $(seq $N); do
    test_run "performance.$i"
done
tuned-adm profile throughput-performance-powersave
for i in $(seq $N); do
    test_run "powersave.$i"
done
```

Then I compared the real time taken for each compilation in the {powersave,performance}.{1,2,3}.txt files.


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

Untested yet, will report tomorrow as a comment.

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

N/A.

Reproducible: Always