porting to Marlin / sailfish #1
Comments
|
Hi @nine7nine! Dynamic stune boost and Vox Populi works differently and cannot co-exist atm. While a Power HAL is a userspace solution (ie. Android OS/frameworks controls it), Dynamic Stune Boost/Cpu-boost is a kernel solution (ie controlled by the Android kernel alone). They cannot co-exist because they can't coordinate between each other. The likely reason why Dynamic Stune Boost doesn't seem to be working is because the Pixel hardcoded the stune boost of 50 in its Power HAL. The only way to use Dynamic Stune Boost is to disable the Power HAL by removing the relevant *.so blob or disabling the perfd service (type "stop perfd" in terminal), which acts on behalf of the Power HAL to toggle the stune boost value. For now you can try disabling perfd in terminal or Ex-Kernel Manager (or other apps), then see if dynamic stune boost does anything and let me know. The downside of disabling perfd (halting Power HAL boosting) is that it handles other kinds of boost besides touch boost. It's important for boosting freqs to max on app launches, providing sustained boosts for certain apps such as VR apps and some camera apps, and other things. But you do sacrifice the convenience of customisability if you go with perfd. Give dynamic stune boost a try and see if it works out for you. I do not recommend using prebuilts of Vox Populi on Pixel because it has not yet been updated for Oreo (not binderized yet). If you track this repo, you'll get an alert when I've updated it hopefully in November. |
|
Hey! thanks for the in-depth reply. You've been very helpful 😁 I can verify that disabling perfd fixes the issue, it now is setting the proper value. I couldn't figure out where the value of 50 came from, so your explanation has helped me better understand the relationship between the power Hal, vox populi and dynamic stune boost. awesome... I'll just add disabling perfd to my custom init for my kernel / in anykernel2... I'm still learning about AES and Schedutil, although I do have years of experience maintainingkernel packages (for archlinux), patching and porting... but mostly with linux-rt... android is more linux-like than linux. lol anyhoo, I'll need to test this for 24hrs or so, to see how things stack up. but I'm hopeful... and clearly my porting effort to sailfish has been successful. your branch for the OP5 has been incredibly helpful, I was able to pull a ton of code, on top of most of the EAS stuff that was kicking around for Sailfish already, in my branch, gathered from elsewhere. I'll let you know how things turn out. thanks again! |
|
Update: So for the most part, everything seems good on my kernel, but I did notice one use case where the input boost did seem to cause issue. Not sure If you can reproduce it or not.... I have this pro-audio music making app called "Beatonal" (Available in Play Store)... It's generally one of the more demanding apps (in terms of performance, low latency, processing) and I found with input boost enabled periodically: The sound would cut out when using touch / manipulating some of the FX settings. In particular; I tend to set really long reverbs and delays/echoes (as it's cpu intensive) I found in this scenario - I would get the dropouts / freeze ups... I'm not sure if that is because of cpu frequency scaling/changes or something else - I may double check my configs against yours - maybe something pops out. idk. That said, with input boost disabled, but dynamic_stune_boost at 10 or 20 (and sched_cfs_boost at 10-20) - the app is smooth as can be, no clicks, pops or underruns (which is an improvement over the stock kernel with Sched)... I'm still experimenting with scheduler tuneables, trying to figure out the best balanced settings (in general), I don't know if you have any insights on this (?) - any recommendations would be great! ... there doesn't seem to be a ton of documentation for Schedutil, although I've been able to get the basics. ... That said; overall, battery life has been great... Also, on Oreo; The Power Hal seems to live in the system//vendor/lib64(and lib)/hw ... power.marlin.so ... there is also a power.default.so, as well. I haven't tried removing either. But out of curiousity, I may just to see if my device still boots - obviously there is still power hall spam in logcat. So I'm curious. |
|
removing power.marlin.so works / boots fine - no spam in logcat |
|
Yup, there's no critical error to removing power.marlin.so! It's pretty
cool that you've done some work maintaining linux packages. Let me know
over the week how your testing goes!
…On Wed, Nov 1, 2017 at 7:52 AM, jrdnjhnstn ***@***.***> wrote:
removing power.marlin.so works / boots fine - no spam in logcat
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/APxGsEQHyz4msd5q-piahAOsYuQK1BOnks5sx7LMgaJpZM4QMHeH>
.
|
|
I wonder though; leaving the power Hal. so in; does that cause any issue, aaside from a ton of log spam? Ya, I maintained PREEMP_RT linux packages for several years, same goes with the nvidia binary drivers (which I use to hack on a bit too). I maintained and contributed some other packages to Archlinux, as well.... handed them to a friend to maintain now. some other FOSS contributions, as well. I'm not a great programmer, but I can fix bugs, compiler issues, etc and occasionally, I come up with good ideas. lol I will for sure let you know how things progress for sure. So far, it's just been the input boost that caused an issue, but I did change some configs, so I'll give it another go... see what happens. I'm following your github now too. ttyl |
|
Nothing critical will happen. It's just that log spam would cause some overhead. |
|
Hey Josh! (I'm Jordan, btw) Ya, I figured it was just spam overhead - I'm been using it without power.marlin.so for a bit now and I do like the lack of spam - as I am in logcat a lot. (as an aside, I also pulled a bunch of fixes from Code Aurora for msm-3.18, which is cleaning up logs, as well. No idea why Google is so lazy about kernel updates)... I can't be positive, but I think the input boost issue might be to do with a config that is (and must be set differently) than your kernel. my 3.18 kernel has RCU backported from 4.9... It was reccomended to use RCU Boost and RT prio 1 for rcu kthread (to avoid priority inversion), I did set it like you did (taken from the Pixel 2 confgi, IIRC?), but my kernel did NOT like that and Logcat showed some complaints.... Not sure if the two correlate or not - but i haven't noticed any problems with my RCU setup, nor keeping input boost disabled (for now). Now, probz on thefollow, like I said; you've been very helpful and I've been using code pulled from your OP5 kernel. So it's been a win win, I think ;) |
|
This is a curiosity, but; Have you considered also making /proc/sys/kernel/sched_cfs_boost, be dynamically set too? The documentation suggests that this (*system wide) tunable is used to bias energy efficiency VS. performance (for all tasks, then?)... I wonder if it could be adapted to just bias the top-app? I may be a bit ignorant on how this tunable works / cgroups / boosting... I assume you have a better understanding than I, So i thought that I'd ask. (?) have a good one! PS: I have a few people testing my kernel, So I should have some progress to report later on / in the week. ttyl |
|
Effectively /proc/sys/kernel/sched_cfs_boost is the same as:
/dev/stune/schedtune.boost
So with that being in the parent folder, it would override every child
folder's value for schedtune.boost.
Also, we dont really need to boost background, system-background, or
foreground. We boost top-app because EAS will bias boosted tasks on big
cores. We dont ever want bg or sys-bg tasks on big cores. They would be
just taking up space and precious task completion latency. Also to take it
further, having stune boosted like we have it and like the pixel 2, stune
also ties into how we set cpusets. WE have cpusets like below:
bg 0-1
sys-bg 0-3
fg 0-3, 6-7
ta 0-7
The reason being that we are making it so only the big cores will ever have
foreground or top-app tasks. Better than that, we are saying that ONLY ta
tasks will have access to cores 4-5. The reason we do this is because when
we boost a tasks (Atm, only boosting top-app tasks) the find_best_target
function will try to place a boosted task on a big core first. It will
iterate in chronological order. So with cpusets like it is, it means that
cores 4-5 will ALWAYS be open for top-app/boosted tasks and will be worked
on ASAP.
If we were to set cpusets so that top-app only has access to cores 6-7,
when find_best_target is trying to find a home for a top-app/boosted tasks,
the code path will check if the tasks is boosted, if yes then it will try
to place it on CPU4 if EAS thinks it has enough capacity (and other
checks).most like, since it would have a foreground tasks on it, it will
then skip CPU 4 and try to place on CPU5, and so on till it finds a spot on
CPU6 or 7 thus wasting precious time to completion.
Back to what you had originally asked, if we set global boost to any value
0 then find_best_target would try to place ALL tasks on a big core first
before finding a home and would cause alot of contention.
I hope this makes sense. There is alot more to how it all works and I am
having to simplify it.
Kind Regards,
Zachariah Kennedy
…On Thu, Nov 2, 2017 at 12:41 PM, jrdnjhnstn ***@***.***> wrote:
This is a curiosity, but;
Have you considered also making /proc/sys/kernel/sched_cfs_boost, be
dynamically set too?
The documentation suggests that this (*system wide) tunable is used to
bias energy efficiency VS. performance (for all tasks, then?)... I wonder
if it could be adapted to just bias the top-app?
I may be a bit ignorant on how this tunable works / cgroups / boosting...
I assume you have a better understanding than I, So i thought that I'd ask.
(?)
have a good one!
PS: I have a few people testing my kernel, So I should have some progress
to report later on / in the week. ttyl
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEB_JmaWfOExIEEaS7dlYcVTYq6Fx7KUks5syf7egaJpZM4QMHeH>
.
|
|
Hey Zacharia, Your simplified explanation makes perfect sense to me, Thanks for jumping in and explaining it! IIRC, like the Pixel 1 has cpusets something like this; bg 0 ...mind you, we have a few less cores to work with... anyhoo, I appreciate your insights. thank you :) |
hi,
sorry for the noise, but; I'm interested in getting your dynamic stune boost && vox populi code running on Sailfish (google pixel 1St gen)....
I've been able to get everything in the kernel running, including cpu-boost + dynamic stune boost, but currently /dev/stune/top-app/stune.boost is defaulting to 50 (?)... /sys/module/cpu_boost/parameters/dynamic_stune_boost = 10. .. but that value seems to be ignored...
I'm at a bit of a loss as to why that is?. ... or where it is getting the value of 50 from?
i'm wondering if there would be a way to hardcode the value to 10?
also, i am curious if any progress has been made on creating a flashable zip for vox populi?
OR is it safe to use your prebuilts for vox populi on my stock pixel rom?
any advice you may have would be incredibly useful and appreciated. thx
The text was updated successfully, but these errors were encountered: