Calling the architected timer adds nontrivial overhead as observed in perf
top, especially since the DVFS functions are hot paths.
Remove all of the sched_clock() calls since they're unneeded by ACPM.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
This driver isn't even compatible with our kernel version, though it is present in the ems folder.
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
This was applied to fix a suspected reboot issue, but it turns out this was not the source of it.
This reverts commit ed828ec374bbd9f3a538a0c92421e9e0074b078f.
Queuing wake-ups is not measurably beneficial in any way. Disable it.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
[Flopster101: Apply to new way of setting features.]
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
(cherry picked from commit 8ddf75b4fb1d7b54a795c1dc70bf480a5f049603)
(cherry picked from commit dbf96ce6987d4361b4135124b81cb40b269366c5)
(cherry picked from commit 3291d145fade85cef2830b9d28fe1c90e154ba9c)
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>
* This is a modified version of schedutil, introducing two new tunables: "efficient_freq" and "up_delay".
* Only raise cpufreq to the non-efficient one (higher than effcient frequencies) if the governor keeps requiring non-efficient frequencies for more than up_delay time.
* Override the new frequencies with the efficient one if the consecutive request time doesn't reach up_delay.
* The two tunables support multiple args, e.g. you can set "1248000 1401600" for "efficient_freq" and set "50 60" for "up_delay", which means it would wait 50ms before raising the frequency to 1248mhz and wait for 60ms before raising the frequency to 1401mhz.
[Flopster101: move the kconfig entry to the proper section.]
As can be seen in the device-tree, this domain is unused for our device:
devfreq_g3d {
dm-index = <0x08>;
available = "false";
cal_id = <0xb040008>;
dm_type_name = "dm_gpu";
};
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
Earlier commits in this series allow battery-powered systems to build
their kernels with the default-disabled CONFIG_RCU_LAZY=y Kconfig option.
This Kconfig option causes call_rcu() to delay its callbacks in order
to batch them. This means that a given RCU grace period covers more
callbacks, thus reducing the number of grace periods, in turn reducing
the amount of energy consumed, which increases battery lifetime which
can be a very good thing. This is not a subtle effect: In some important
use cases, the battery lifetime is increased by more than 10%.
This CONFIG_RCU_LAZY=y option is available only for CPUs that offload
callbacks, for example, CPUs mentioned in the rcu_nocbs kernel boot
parameter passed to kernels built with CONFIG_RCU_NOCB_CPU=y.
Delaying callbacks is normally not a problem because most callbacks do
nothing but free memory. If the system is short on memory, a shrinker
will kick all currently queued lazy callbacks out of their laziness,
thus freeing their memory in short order. Similarly, the rcu_barrier()
function, which blocks until all currently queued callbacks are invoked,
will also kick lazy callbacks, thus enabling rcu_barrier() to complete
in a timely manner.
However, there are some cases where laziness is not a good option.
For example, synchronize_rcu() invokes call_rcu(), and blocks until
the newly queued callback is invoked. It would not be a good for
synchronize_rcu() to block for ten seconds, even on an idle system.
Therefore, synchronize_rcu() invokes call_rcu_flush() instead of
call_rcu(). The arrival of a non-lazy call_rcu_flush() callback on a
given CPU kicks any lazy callbacks that might be already queued on that
CPU. After all, if there is going to be a grace period, all callbacks
might as well get full benefit from it.
Yes, this could be done the other way around by creating a
call_rcu_lazy(), but earlier experience with this approach and
feedback at the 2022 Linux Plumbers Conference shifted the approach
to call_rcu() being lazy with call_rcu_flush() for the few places
where laziness is inappropriate.
And another call_rcu() instance that cannot be lazy is the one
in queue_rcu_work(), given that callers to queue_rcu_work() are
not necessarily OK with long delays.
Therefore, make queue_rcu_work() use call_rcu_flush() in order to revert
to the old behavior.
Signed-off-by: Uladzislau Rezki <urezki@gmail.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This imports a couple of memory management hacks used by Oplus (Oppo, Realme, and OnePlus) on their recent devices. This patch does the following:
- Add a separate swappiness (default 60) value to use if task isn't handled by kswapd
- Don't throttle tasks with OOM value < 0
- Increase zsmalloc's maximum page order
Signed-off-by: Dark-Matter7232 <kerneldeveloper7232@gmail.com>
[TenSeventy7: Make the Kconfig more descriptive]
Signed-off-by: John Vincent <git@tenseventyseven.cf>
[Flopster101: Adapt to 5.10. Hardcode ISOLATED_BITS value and don't set ZS_MAX_ZSPAGE_ORDER]
Signed-off-by: Nahuel Gómez <nahuelgomez329@gmail.com>
Change-Id: Id6fe0d3ebf7eabb423f2ec64d79075c0e3ba9e14
Signed-off-by: Samuel Pascua <sgpascua@ngcp.ph>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Commit "rcu: Create RCU-specific workqueues with rescuers" switched RCU
to using local workqueses and removed power efficiency flag from them.
This caused a performance regression that can be observed in Geekbench 5
after enabling CONFIG_WQ_POWER_EFFICIENT_DEFAULT: score went down from
760/2500 to 620/2300 (single/multi core respectively).
Add WQ_POWER_EFFICIENT flag to avoid this regression.
Change-Id: I2c4f41faa55548f9e81a1c0cbe10703948062d89
