Messages in this thread | | | Subject | Re: [PATCH 0/1] drivers: devfreq: use DELAYED_WORK in DEVFREQ monitoring subsystem | From | Lukasz Luba <> | Date | Thu, 30 Jan 2020 11:47:57 +0000 |
| |
Hi Chanwoo, MyungJoo,
Gentle ping. The issue is not only in the devfreq itself, but also it affects thermal. The devfreq cooling rely on busy_time and total_time updated by the devfreq monitoring (in simple_ondemand). Thermal uses DELAYED_WORK and is more reliable, but uses stale data from devfreq_dev_stats. It is especially visible when you have cgroup spanning one cluster. Android uses cgroups heavily. You can make easily this setup using 'taskset', run some benchmarks and observe 'devfreq_monitor' traces and timestamps, i.e. for your exynos-bus.
The patch is really non-invasive and simple. It can be a good starting point for testing and proposing other solutions.
Regards, Lukasz
On 1/27/20 3:17 PM, lukasz.luba@arm.com wrote: > From: Lukasz Luba <lukasz.luba@arm.com> > > Hi all, > > This patch is a continuation of my previous work for fixing DEVFREQ monitoring > subsystem [1]. The issue is around DEFERRABLE_WORK, which uses TIMER_DEFERRABLE > under the hood which will work normally when the system is busy, but will not > cause a CPU to come out of idle and serve the DEVFREQ monitoring requests. > > This is especially important in the SMP systems with many CPUs, when the load > balance tries to keep some CPUs idle. The next service request could not be > triggered when the CPU went idle in the meantime. > > The DELAYED_WORK is going to be triggered even on an idle CPU. This will allow > to call the DEVFREQ monitoring in reliable intervals. Some of the drivers might > use internal counters to monitor their load, when the DEVFREQ work is not > triggered in a predictable way, these counters might overflow leaving the > device in undefined state. > > To observe the difference, the trace output might be used, i.e. > > echo 1 > /sys/kernel/debug/tracing/events/devfreq/enable > #your test starts here, i.e. 'sleep 5' or 'dd ' or 'gfxbench' > echo 0 > /sys/kernel/debug/tracing/events/devfreq/enable > cat /sys/kernel/debug/tracing/trace > > When there are some registered devfreq drivers, you should see the traces > 'devfreq_moniotor' triggered in reliable intervals. > > The patch set is based on Chanwoo's devfreq repository and branch > 'devfreq-next' [2]. > > Regards, > Lukasz Luba > > [1] https://lkml.org/lkml/2019/2/12/1179 > [2] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-next > > > Lukasz Luba (1): > drivers: devfreq: add DELAYED_WORK to monitoring subsystem > > drivers/devfreq/Kconfig | 19 +++++++++++++++++++ > drivers/devfreq/devfreq.c | 6 +++++- > 2 files changed, 24 insertions(+), 1 deletion(-) >
| |