yashsingh1/xdaforums huggingface dataset:
[Nexus 6  Original Android Development] hellsgod:
I'm currently running mako_hotplug from franco with a load threshold of "0", which means all cores are online on screen on. franco removed all suspend/resume routines from his driver, so I guess there's another part who handles this. He just says: "Core suspend routines take care of that for every suspend/resume cycle." Refer back to this commit

It seems both (mako and mpdec) fires all cores online and offline during suspend:

<6>[ 146.825076] Enabling non-boot CPUs ...
<6>[ 146.826377] Added affinity for 1242 processes to cpu 1
<6>[ 146.826606] CPU1 is up
<6>[ 146.827566] Added affinity for 1242 processes to cpu 2
<6>[ 146.827767] CPU2 is up
<6>[ 146.828839] Added affinity for 1242 processes to cpu 3
<6>[ 146.828845] Released forced binding to cpu0 for 1242 processes
<6>[ 146.829128] CPU3 is up

I used another hotplug in the past where I could set max cores on suspend. I've set it to "1" and never had any problems. I actually don't see the point to fire up all cores on suspend, instead of only one or two.

For input boost you could use cpu_boost or just the governor, yes. I've played around with some values in the past, my two older devices (N4 and N5) are using 1 second input boost (compared to the stock 3 secs its 1/3) and on shamu I've now switched from francos 40ms to 500ms. Night and day :D The last jitters are mostly sorted out. There are some experiments with low min freq vs. higher min freq and it seems a higher min freq (like the boosted state for 3 secs on stock) can save some power, because you don't have unnecessarly up and down scaling. I think this 3 secs are just too long imho. I'm currently testing out if I stay on 500ms or raise it to 1 sec like on my other devices.

hells
[Nexus 6  Original Android Development] mjohnson4580:
Sio scheduler ??
[Nexus 6  Original Android Development] bbedward:
The origins of sio scheduler actually live with me :laugh:

It was made years ago for zen kernel on the desktop (which I maintained) then a couple years ago I extended it a little bit for the gnex zen kernel I think.

But do you see any difference with it :p it seems like all the I/o schedulers perform about the same, I think the limiting factor is the speed of the hardware.
[Nexus 6  Original Android Development] mjohnson4580:
I always ran it on my note 2 an felt it was smoother but that could have just been my imagination.
[Nexus 6  Original Android Development] bbedward:
Adding it is harmless because of the pluggable I/o scheduler system in place. I can add 20 schedulers without any harm :p

I will look at my gnex source and pull out the slightly revised version I did and add it in.
[Nexus 6  Original Android Development] mjohnson4580:
Thank you i would greatly appreciate it
[Nexus 6  Original Android Development] Xileforce:
Yea this is how I've been using 4 core mode too. I still am using the old 80% load as the default though due to less overhead when hotplugging with bfs. I set touchboost to 150ms but I'll have to give 500 a try :)
[Nexus 6  Original Android Development] bbedward:
I don't know why anybody is messing with this or moving stuff to the governor after observing the following.

- CPU hotplugs on suspend/resume as expected from either core suspend driver or msm pm driver. MP decision is unrelated

- you can completely configure input-boost in the userspace

Why make it governor specific I'm not sure. Maybe related to the hotplug driver.

Anyway, anybody who wants to adjust input boost can just disable mp decision and do it themselves. I see no reason to do it any other way unless you want active hotplugging :p
[Nexus 6  Original Android Development] hellsgod:
You'll may not really notice much of a difference between 150ms and 500ms. I've set it to 250ms for testing and it seemed to just jitter a little bit more after long scrolling. But you have to look really closely to notice it. Keep me updated what you think about it :)

hells

---------- Post added at 05:45 AM ---------- Previous post was at 05:42 AM ----------

The solution franco offers is an independent touch listener, you only have to add it to the governor(s) you're using. So its not that governor specific :) I'd like to offer my users the possibilty to mess around with hot plugging (and touch boost), even if I don't use any active hotplugging anymore :)

hells
[Nexus 6  Original Android Development] bbedward:
If you have to have code in the governor to handle it it's governor specific ;) the solution cpu-boost offers is not governor specific and does the same thing.

Yes it makes sense to keep the option for active hot plugging :good: If the user isn't insistent on active hot plugging then they can get the input boost they want even on a stock kernel.
[Nexus 6  Original Android Development] gamewarden234:
To each their own but bfs scheduler is the bomb. I have gone from 5 hours SOT to almost 7 from doing nothing different but using this kernel. Hells is very similar. I have the same rom with both kernels in multirom with a third with the old scheduler and there is clearly a significant difference. Only a matter of time before it becomes standard on all kernels in my opinion. Very snappy at a lower cpu speed than the old scheduler. Bravo
[Nexus 6  Original Android Development] Xileforce:
But doesn't CPU boost also do other boosts? Not just on touch? My guess is Franco does it so he can only have the touchboost portion. I'm not sure why he didn't just integrate it all into the touchboost driver though, rather than making it require a governor with support for it.
[Nexus 6  Original Android Development] hellsgod:
cpu_boost offers the possibility to boost cpus in general, yes. But if you don't enable it, you can use it for input boost only.

hells
[Nexus 6  Original Android Development] bbedward:
I don't know the reason. I'm not saying there's a bad one for it, maybe it's desirable to do to it on the same sample period as interactive normally takes. I dropped mp decision and set input boost to 1s and it seems to work fine. I think any user could do the same :) , except if they want active hotplug they can't do it here. I wrote a pretty nice hotplug algorithm for the gnex, but not going to mess with that here because hot plugging is so 3 months ago :p

Cpu-boost does input boost and boost on cgroup task migrations. (I think that's it, but it's designed to allow easy addition for other potential boosts google or others may add in the future)

The former makes sense because you want to minimize userspace lag. The latter makes sense because these migrations have been known to be pretty CPU intensive. There's even been a few Linux threads about the task migration causing sluggishness.

The latter doesn't matter on BFS. You can still change the module migration load threshold but it won't do anything on BFS :p

It makes sense why that would be desirable without BFS and with cgroups though, since it appears it's known such migrations cause lagg.

--

The one I wrote for the gnex was a step up type algo. Of course the gnex only had two cores but it turned on cores as load linearly increased and only if load stayed for a certain threshold. Pretty cool I think.
[Nexus 6  Original Android Development] Xileforce:
O_o too many words. But I think I get what your saying. I don't use CPU boost myself so I don't know much about it. Can CPU boost be tweaked to change the boost duration?
[Nexus 6  Original Android Development] bbedward:
If you take a stock kernel, stock ROM, and add root you can set it to boost for 40,100,1000,3000ms (or anything else) that's all I know.

I don't know why we are disabling CPU boost except for the fact there's an alternative touch boost :)
[Nexus 6  Original Android Development] Xileforce:
Y don't u just get on the bandwagon! Stop thinking about stuff! In other news that 500ms boost seems to be working very nicely hells!
[Nexus 6  Original Android Development] omvir:
Which values would you have to tweak to mess with the boost duration?
[Nexus 6  Original Android Development] Xileforce:
I'm not entirely sure if you use CPU boost. You may try synapse. You will have to flash ukm first though. If my memory is correct you can tweak CPU boost in synapse.
[Nexus 6  Original Android Development] djcsurf:
Kernel Adiutor has CPU boost options.
[Nexus 6  Original Android Development] :
Xileforce is correct. Input boost is in Synapse app under CPU tab.. See pic..
[Nexus 6  Original Android Development] rignfool:
AFAIK...

All mpdecision does on the shamu now is turn min frequency to 1497 for 3 seconds and destroy battery life

EDIT: it also repluggs cores taken offline by the thermal driver for low battery or heat situations
[Nexus 6  Original Android Development] bbedward:
I think the effects of this are overstated, but I don't like the min bump.

Before relaying this behavior to CPU boost I need to write a zen decision driver to ensure cores come online when screen is on because this doesn't always happen without mp decision
[Nexus 6  Original Android Development] djcsurf:
Looks like you have a changelog for v18 "The Untouchables" lol
[Nexus 6  Original Android Development] bbedward:
Yea I don't see a problem with relaying the mp decision functionality to the kernel :)

I just prefer to make my own solution than to use another one :)

CPU boost seems fine for input boost, I just need to add the online/offlining of cores for screen on/off probably.

It will also resolve some of the any kernel lag because I'm guessing some ROMs disable mp decision and people lose cores permanently and such.
[Nexus 6  Original Android Development] bbedward:
BTW, Go Cavs complete the sweep :laugh:

I hope you are all the enjoying your Sunday as well :highfive:
[Nexus 6  Original Android Development] Megaflop666:
GO CAVS!
[Nexus 6  Original Android Development] bbedward:
My suggestion is stock, it was just an example.

The behavior itself can pretty much be manipulated to do anything. Just be careful in editing that file.
[Nexus 6  Original Android Development] Circaflex:
what app are you guys using to control the kernel? I have tried trickster and fku app, both default to CFQ scheduler and do not show a BFS option, is there something wrong on my end?
[Nexus 6  Original Android Development] bbedward:
CFQ is is an I/O (disk) scheduler, while BFS is the CPU Scheduler. (The one you are thinking of is BFQ, which isn't in this kernel - but I can add it as it's pretty trivial and unobtrusive if you want)

The cpu scheduler is always BFS and cannot be changed in the userspace.
[Nexus 6  Original Android Development] Circaflex:
thanks, figured it was a brainfart on my end
[Nexus 6  Original Android Development] bbedward:
Zen5

I mostly wanted to put this up today to smooth out the f2fs issues on zen4. But it came with some other stuff too.

I won't keep issuing updates every day anymore I promise :crying:

3.10-zen5 "Day Drinking" (Android 5.1 Only)

I suggest wiping cache before flashing

Changes:

Added kexec-hardboot support for multirom

Adjusted f2fs default mount options (nobarrier on /data) (inline_dentry, extent_cache on /data and /cache). Zen4 f2fs was acting really slow, this fixes it

Build f2fs with security labels for seliinux, which was missing on zen4

Added BFQ v7r7

Added 2.95GHz and 3.03GHz overclock steps

BFS: refactor sched_init_smp

BFS: cleanup/remove unused above_background_load function
[Nexus 6  Original Android Development] MizzouBrent:
Just want to say this kernel is running like a dream on chroma. Great work!
[Nexus 6  Original Android Development] mimsiroll:
No idea regarding the stock value op, im a total newbie but i really like your kernel.. Its not getting warm and I've already set my CPU to throttle at 20% ~2.3ghz , cpu 2-3 to shutdown at 20% as well but after i check with system monitor only cpu 3 shuts and for gpu i made it to throttle at 400mhz? At 20% as well..but if you could enlighten me I'll be happy to..and thank you.

[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 80
thresholds_clr 79
actions cpu
action_info 2265600

[BAT-SOC-HOTPLUG]
algo_type monitor
sensor soc
sampling 5000
thresholds 80 80
thresholds_clr 81 81
actions hotplug_3 hotplug_2
action_info 1 1

[BAT-SOC-GPU]
algo_type monitor
sensor soc
sampling 5000
thresholds 70
thresholds_clr 71
actions gpu
action_info 389000000
[Nexus 6  Original Android Development] bbedward:
I was just saying I'm happy with the stock behavior :p

But you can manipulate it to behave however you want, if you want to throttle at 30%, 10%, 5%, etc. There's no limitations but you definitely wanna backup the original file and make sure your changes are correct before saving/restarting the thermal-engine.
[Nexus 6  Original Android Development] mimsiroll:
Ive done it as what you told on your 2#post and some math hahaha

Now im liking the coding and stuff..

But can you kindly check what i did..i reposted a code on my previous comment, hope you dont mind..but if its okay can i just copy your build then ill place mine since i prefer the op's work .
[Nexus 6  Original Android Development] bbedward:
Yours looks correct, this is what it'll do

Scale CPU Frequency to ~2.2GHz at 20% battery, revert back to max at 21%

At 20% battery, remove CPU2 and CPU3 (effectively you will be dual-core at 20% battery and below)

At 30% battery remaining, scale GPU down to 389MHz

I know everybody else has been sensitive on making changes to the thermal-engine, but I think it has been overblown a little.

If you experience any issues after changing the battery stuff I would just revert to the stock file.
[Nexus 6  Original Android Development] mimsiroll:
Op, another quick tackle, regarding the OC to 3ghz whats the suitable uv for it? Should i remain at stock value? Will it change the temperature? Im using franco kernel updater to tweak it though.. And i know its a redundant question ever since the beginning of android..what's the benefit of Oc'ing at 3ghz??

And are you using your n5 as your reference to your compiling? Either way this is a badass kernel!
[Nexus 6  Original Android Development] bbedward:
I can't really say, I think the only benefit may be higher benchmarks, voltage will vary from device to device.

The higher the voltage the higher the temperature though, I'm not convinced I will keep the 3ghz option yet.

But I have an N6 now too
[Nexus 6  Original Android Development] mimsiroll:
Using 3ghz atm, then does your kernel support volume rocker Wake? I already turn it off on chroma rom but still insisting..
[Nexus 6  Original Android Development] bbedward:
I don't have anything added for that, if it requires anything in the kernel (I haven't seen any patches for it)

I only added screen wake stuff.
[Nexus 6  Original Android Development] bbedward:
3.10-zen5_rev1 "Day Drinking Sunday = Rough Monday" (Android 5.1 Only)

I suggest wiping cache before flashing

Changes:

Added kexec-hardboot support for multirom

Adjusted f2fs default mount options (nobarrier on /data) (inline_dentry, extent_cache on /data and /cache). Zen4 f2fs was acting really slow, this fixes it

Build f2fs with security labels for selinux

Added BFQ v7r7

Added 2.95GHz and 3.03GHz overclock steps

BFS: refactor sched_init_smp

BFS: cleanup/remove unused above_background_load function

I had to revert the 2.95 and 3.03GHz steps for now. There may be additional code in cpufreq that's required to block these frequencies from being used.

If i had to guess, when the device boots up it sets max_frequency to 3.03GHz before the ramdisk init gets a chance to bring it back down to the stock 2.6.

Some devices had issues booting, this fixes it.
[Nexus 6  Original Android Development] otisman:
What recovery is working on 5.1 for f2fs much alohas
[Nexus 6  Original Android Development] Circaflex:
I think you are correct about the max freq at boot, I had a test kernel from franco that did the same and would boot all the way up at that speed, I had to keep my phone plugged in to boot at that speed (don't ask why that worked) and I would have to force a lower clock or raise the volts to be able to use those speeds
[Nexus 6  Original Android Development] bbedward:
Dhacker has one built with f2fs support. It's twrp 2.8.5.0

On dev-host:

http://d-h.st/4oKo
[Nexus 6  Original Android Development] otisman:
Much alohas
[Nexus 6  Original Android Development] riassan:
Man nice to see you bro. Been some time Evo days. Enabling screen out and working aosp kernel. Haha
[Nexus 6  Original Android Development] rignfool:
I truly find amazing how much you Cavs fans hated LeBron when he left... And now you forget how he left you just because you guys are winning...
[Nexus 6  Original Android Development] bbedward:
I'm from Cleveland. I love all the Cleveland teams and they've been starved from any championship since the 60s.

Of course people were pissed when he left, but overall it's about the team success. Also lebron hate him or love him has significant charity events and does lots of things specific to north east ohio and Akron. Not going to stop cheering for my city because he left the Cavs 5 years ago or whatever.

----

On another note. I know I said I wouldn't mess with much but I am going to delegate all the responsibility of mp decision to the kernel. I will retain stock behavior, but rely on the kernel to make the decisions instead of the mp decision binary.
[Nexus 6  Original Android Development] Megaflop666:
Cavs win, 'nuff said!
[Nexus 6  Original Android Development] bbedward:
Now the Indians just have to figure out Detroit :crying:
[Nexus 6  Original Android Development] Megaflop666:
Hate baseball so I could care less... And we have a great team down here in cinci...
[Nexus 6  Original Android Development] bbedward:
Yea we don't care about national league, just hate Detroit.

But I love baseball. Its the best excuse to go drink and eat on a summer afternoon.
[Nexus 6  Original Android Development] wrongway213:
Check the location guys.. it's real out here. GO CAVS!
[Nexus 6  Original Android Development] bbedward:
Nice, you should come to Rover fest 2015 ;)
[Nexus 6  Original Android Development] wrongway213:
If a babysitter/money allows I just might man
[Nexus 6  Original Android Development] bbedward:
[MENTION=1481114]purian23[/MENTION] and me will be there :laugh:

You probably won't get the best impression of me from there.
[Nexus 6  Original Android Development] wrongway213:
Another local? Man.. even if I am not using Zen this is a thread I will stop by in.

Speaking of, how does it run with mp-decision disabled? I've seen before in the past (first few versions of Zen I think) that you recommended keeping it enabled, but talk of it the last few pages makes me wonder if you are leaning another way, i.e. enabling a hotplugging option in the future or something. Honestly that's the only thing that kept me off Zen initially, my hatred for mp-decision coupled with you recommending it be enabled - does the kernel run well with it disabled now on Zen 17? Is using CPU boost as it is now a way to avoid the boost to 1497 from mp-decision while still getting some sort of input boost? I thought stock CPU boost emulated that behavior from mp-decision - or am I wrong on that entirely? Basically I am curious about the last few pages and what exactly they mean to the end user, as opposed to for development purposes. I hope this jumbled mess of a post makes sense - my apologies if it does not.
[Nexus 6  Original Android Development] bbedward:
It's impossible to not keep it enabled with zen as it sits now

Because when phone sleeps or thermal driver shuts cores down it never wakes them back up if mp decision is disabled.

So basically what I am doing with zen18:

- I wrote my own "msm_zen_decision" driver that removes all cores after a certain time off (if they aren't already removed) and brings all cores online when screen is on no matter what. Of course it uses in-kernel methods to avoid races between itself and any other kernel driver or user space driver doing such hot plugs.

- secondly I'm expliicitly defining defaults on CPU-boost for 1.497GHz and 3 (or more likely 1.5) seconds for the input boost duration

All in a configurable way.

This basically replicates the exact same behavior as stock and allows user configurability while not changing min_freq like the mp decision binary does :)

Essentially it's a kernel replacement of what should be in the kernel to begin with
[Nexus 6  Original Android Development] wrongway213:
Ah, makes sense why I couldn't get it to do what I wanted in Synapse, haha. Thanks for the thorough explanation.. I gotta say, I can't wait til Zen 18 is ready then. I really loved BFSand it has Faux Sound and DT2W, so if I could not have to deal with mp-decision I'd be a happy guy.. definitely can't wait to see msm_zen_decision driver in action. I generally love hotplugging, but if this does what it is supposed to from your description maybe I finally will not have the need for it.
[Nexus 6  Original Android Development] bbedward:
Nearly replicating stock behavior but adding user configurability is my goal ;)
[Nexus 6  Original Android Development] Megaflop666:
Pm if you need a Guinea pig. I'll be out for my evening walk with the wife for next hour but I'm available after that.
[Nexus 6  Original Android Development] papikev:
This is a UI smoothness post relating to the phone dialer. This is the only area where I find it to be quite choppy. Everywhere else the kernel performs outstanding. If someone else can confirm, that would be cool. Pull up the dialer, maybe dial 123 or whatever number, then hang up (make sure the dialer pad is still up before you hang up) . When the dial pad retracts, it is quite choppy. I'm on Chroma latest with Zen 17 boot.img. Not a big deal, but since the bfs scheduler is alot about smoothness, I thought I would mention this to see if that is something worth looking into.
[Nexus 6  Original Android Development] djcsurf:
Nearly replicating, but kicking stocks ass!! GOAL... :D
[Nexus 6  Original Android Development] VECTUS:
And you sir, are achiving it. 17 has been darn near perfect for me...:good::good:
[Nexus 6  Original Android Development] yellowman82:
Hmmmm this is why I guess I stop lowering the minimum GHz. I remembered lowering it to 300mhz and my phone would completely lag and stutter for some odd reason.

I kept testing it raising the minimum step by step until I notice less lag and stutter starting around 900mhz+ but honesty having it at 1497 was the much better performance.
[Nexus 6  Original Android Development] bbedward:
This is a disabling of mp decision on zen that prevents it from boosting on user input.

I don't really see too much there. Maybe it is :) but it isn't slow in the actual closing. Perhaps android is giving the dialer a really low priority by default causing BFS to neglect the task related to it a bit as it's considering it a non-interavtive task?

I don't really see much stutter myself though :(
[Nexus 6  Original Android Development] oak:
DO yourself a favor and ditch the stock dialer for ExDialer. It is instant fast and smooth. It's on Play Store and there is a thread on XDA.
[Nexus 6  Original Android Development] Xileforce:
Its all about the warriors guys....cmon...nobody?
[Nexus 6  Original Android Development] bbedward:
Sorry son. Only Ohioans modify their phones.
[Nexus 6  Original Android Development] Xileforce:
:( the hate is real. This thread is like an Ohioan nest!
[Nexus 6  Original Android Development] yellowman82:
I'm actually going for the warriors even though they not my team but I love steph curry he's a true sniper.
[Nexus 6  Original Android Development] Megaflop666:
South west Ohio in da house!
[Nexus 6  Original Android Development] Xileforce:
He is...and that come back....
[Nexus 6  Original Android Development] Megaflop666:
Because there isn't much else to do here. Lol
[Nexus 6  Original Android Development] bbedward:
I only support Ohioans of course.

Maybe tomorrow I will push a test up to pushbullet. Will enable zen decision in my ramdisk and in any kernel . but I can't say any apps will add support for it.

Hopefully app support doesn't matter anyway because it uses kernel methods to block all hot plug events so it doesn't conflict with the others. And it only operates on screen on/off