Hi Zachariah,
On 3/22/19 7:01 PM, Zachariah Kennedy wrote:
Good day,
First, I apologize for the information overload below. I just wanted to make sure to provided as much detail as possible.
I do kernel development as a hobby for XDA and other communities. For a given device that we support, we tend to follow the same sched changes as Google and will pull in changes from upstream. One of the devices we dev for is the OnePlus6 and 6T. It uses the same SD845 SOC as the P3. Long story short, I started to notice an issue that we did not have on our Oneplus5 Device (SD835 same as the Pixel 2). When boosting top-app/schedtune.boost to 50 for example, it would appear to boost both small and big cores. With a boost of 50, this means both clusters would be running at 1766MHz and above. But this behavior was inconsistent. I could reboot, and sometimes only the big cluster would appear to be affected by the stune boost but it would seem that after hours/days of up time, the issue would occur again and both clusters would be affected.
There is this additional boost feature of "boost policy" in the P3 device kernel (I'm on android-9.0.0_r0.66, commit dff097cd6c51 "Merge branch 'android-msm-bluecross-4.9-pi-qpr1' into android-msm-bluecross-4.9-pi-qpr2"). You won't find this in the v4.9 Android Common Kernel.
kernel/sched/sched.h:
1111 enum sched_boost_policy { 1112 SCHED_BOOST_NONE, 1113 SCHED_BOOST_ON_BIG, 1114 SCHED_BOOST_ON_ALL, 1115 };
sched_boost_policy() is also used in fair.c. I wonder if this has something to do with what you see.
I assume you haven't changed the kernel build nor the scheduler related runtime configuration:
Jut to make sure, can you share:
# zcat /proc/config.gz | grep "SCHED|CGROUP"
# for f in /proc/sys/kernel/sched_[^d]*; do echo -e "$f \c"; cat $f; done
In case you want to put extra trace_printks into the kernel stack and you use trace-cmd, you might want to revert commit f9b19a92ea7d "tracing: do not leak kernel addresses".
Best Regards,
-- Dietmar