Skip to content

Tags: thisiskimocoder/android_kernel_google_zuma

Tags

20240828

Toggle 20240828's commit message
cpufreq: schedutil: Allow single-CPU frequency to drop without idling

Given that a CPU's clock is gated at even the shallowest idle state,
waiting until a CPU idles at least once before reducing its frequency is
putting the cart before the horse. For long-running workloads with low
compute needs, requiring an idle call since the last frequency update to
lower the CPU's frequency results in significantly increased energy usage.

Given that there is already a mechanism in place to ratelimit frequency
changes, this heuristic is wholly unnecessary.

Allow single-CPU performance domains to drop their frequency without
requiring an idle call in between to improve energy. Right off the bat,
this reduces CPU power consumption by 7.5% playing a cat gif in Firefox on
a Pixel 8 (270 mW -> 250 mW). And there is no visible loss of performance.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

20240820

Toggle 20240820's commit message
sched/fair: Disable CACHE_HOT_BUDDY to leverage DynamIQ Shared Unit

In a similar vein to setting sysctl_sched_migration_cost to zero, disable
CACHE_HOT_BUDDY to better leverage the DynamIQ Shared Unit (DSU). With the
DSU, L2$ and L3$ locality isn't lost when a task is migrated to another
intra-DSU core.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

20240611

Toggle 20240611's commit message
media: videobuf2: Perform a synchronized wake for waiting processes

Processes waiting to consume buffers are handed off buffers from the kernel
with the kernel's producer often going to sleep right after. This matches a
synchronized wake pattern and can benefit from improved scheduling by
making the scheduler aware of it via a sync wake.

Perform a synchronized wake in vb2_buffer_done() so waiting processes can
be scheduled in sync with kernel-side buffer producers.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

20240512

Toggle 20240512's commit message
sched/core: Forbid Unity-based games from changing their CPU affinity

Unity-based games (such as Wild Rift) like to shoot themselves in the foot
by setting a nonsense CPU affinity, restricting the game to a narrow set of
CPU cores that it thinks are the "big" cores in a heterogeneous CPU. It
assumes that CPUs only have two performance domains (clusters), and
therefore royally mucks up games' CPU affinities on CPUs which have more
than two performance domains.

Check if a setaffinity target task is part of a Unity-based game and
silently ignore the setaffinity request so that it can't sabotage itself.

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>

20240402

Toggle 20240402's commit message
zuma_defconfig: Enable -Werror

Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>