I don't want to create a lengthy post, but I was wondering if anyone had issues on Lunar Lake (laptops). I'm using the new Energy Aware Scheduler that is supposed to distribute load among E-cores and place hard tasks on P-cores. However, what this often leads to is high switching between E-cores and P-cores (I think). For difficult tasks like untaring a 30 GB file, it can't decide whether it wants to use a single P-core for 3 seconds at a time or to use all P and E cores in a chaotic sinusoidal fashion that results in the entire system (Wayland included) lagging. If the E-cores are busy with P-core tasks, they wouldn't be able to handle lightweight tasks that must be done on time (Wayland).

It's not just tar, it can be Firefox, Vscode, or IntelliJ. YouTube seems fine on its own, but as soon as I enter Google Maps or try to multitask between two things it enters a fritz as it can't decide which cores should be handling the unnecessary 3D rendering that Google uses. I've enabled 3D acceleration to the fullest extent that Firefox offers and can verify through nvtop. I'm on one of the latest stable kernels (6.16.7-1-default) and am using TLP and Wayland since they're the only things that get decent battery life on this computer (4.5-5.0 watts during coding and web browsing). Below is my TLP configuration as well as what it reports. Current distro is OpenSUSE Tumbleweed. I'm not sure how it operates over a tailored distro like CachyOS.
10-tlp.conf
CPU_DRIVER_OPMODE_ON_AC=passive
CPU_DRIVER_OPMODE_ON_BAT=passive
CPU_SCALING_GOVERNOR_ON_AC=schedutil
CPU_SCALING_GOVERNOR_ON_BAT=schedutil
CPU_ENERGY_PERF_POLICY_ON_AC=performance
CPU_ENERGY_PERF_POLICY_ON_BAT=power
PLATFORM_PROFILE_ON_AC=performance
PLATFORM_PROFILE_ON_BAT=low-power
CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=1
START_CHARGE_THRESH_BAT0=0 # dummy value
STOP_CHARGE_THRESH_BAT0=1
tlp-stat -p
***
TLP 1.8.0 --------------------------------------------
+++ Processor
CPU model = Intel(R) Core(TM) Ultra 7 256V
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver = intel_cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor = schedutil
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors = ondemand performance schedutil
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 400000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq = 4700000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq = 400000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq = 4700000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference = power [EPP]
/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences = default performance balance_performance balance_power power
/sys/devices/system/cpu/cpu1..cpu7: omitted for clarity, use -v to show all
/sys/devices/system/cpu/intel_pstate/status = passive
/sys/devices/system/cpu/intel_pstate/min_perf_pct = 9 [%]
/sys/devices/system/cpu/intel_pstate/max_perf_pct = 100 [%]
/sys/devices/system/cpu/intel_pstate/no_turbo = 0
/sys/devices/system/cpu/intel_pstate/hwp_dynamic_boost = (not available)
/sys/devices/system/cpu/intel_pstate/turbo_pct = (not available)
/sys/devices/system/cpu/intel_pstate/num_pstates = (not available)
/sys/module/workqueue/parameters/power_efficient = N
/proc/sys/kernel/nmi_watchdog = 0
+++ Platform Profile
/sys/firmware/acpi/platform_profile = low-power
/sys/firmware/acpi/platform_profile_choices = low-power balanced performance
My UEFI is configured to disable Intelligent Cooling and the platform setting is set to prioritize power over performance, but the same thing happens regardless of that setting.
9/25: seems to happen when leaving hibernation.
I believe I have found the reason. I somehow correlated this to swap usage, despite my system not using a lot of memory, so I decided to write a simple C program, below:
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#define GB 9
int main(void) {
const int allocsize = 1024 * 1024 * 64;
const long long target = 1024LL * 1024 * 1024 * GB;
for (long long i = 0; i < target; i += allocsize) {
int *p = malloc(allocsize);
memset(p, 0xff, allocsize); // make sure it's not optimized away
}
printf("Done\n");
char c;
scanf("%c\n", &c);
}
9GB was how much I needed to trigger it. Ran swapoff -a and no longer having that problem. It seems like even 100 MB of used swap was causing a lot of problems. I still had the same performance issues with swappiness=0 and swapon -a despite swap not being touched and the memory allocation being the same.
The only moral justification for an AI rewrite. Love it.