[Galaxy Note 3 Android Development] Yank555:
I quickly jump in (very busy at work atm)...

Some clarifications what does exatcly what on Qualcomm devices (like Note 3).

Governor

:

A governor will only handle frequency scaling (and per core !), sou you could have different governors active at the same time handling a respective core if you want (but you don't want that, trust me ;)).

This is a possible sceanrio (but as I said a bad idea) :

core 0 : ondemand

core 1 : interactive

core 2 : conservative

core 3 : performance

Unlike on i9300 (Exynos), the governor does no hotplugging, so it will neither turn a core on nor off (at least all governors I've seen so far on this device).

Hotplug driver

:

There are some in-kernel hotplug drivers, like

intelliplug

(faux123's creation) or

msm_hotplug driver

(can't remember the dev's name sorry). These will only handle hotplugging, taking cores on- and offline, but won't touch the frequencies.

mpdecision

:

And then there's this strange thingy :cyclops:

This is Qualcomm's way to close source their CPU driver by making it a daemon (resident binary) rather than coding it into the kernel which would force them to release it publicly.

And I mean what I write, CPU

driver

, because it will both handle hotplugging, plus interfere with frequency scaling.

First it will put cores on- and offline.

Second, it will change scaling min and max to force the governor to do what mpdecision wants, when the governor does not !

And to do this, it will write to the very same files all CPU apps write to as well, which is why for most values won't stick, mpdecision overwrites them all the time.

Conclusion

:

If you disable mpdecision, you'll end up with whatever cores were online will be online (that can be 1,2,3 or 4), none will go neither on, nor offline anymore, you don't have an active hotplug driver anymore.

Scaling min/max will eventually stay at what you set them, since there's no mpdecision running to mess with them.

But you need to be certain, there's no "mpdecision" task left running in the background !! Killing it won't help, it's a deamon, it will respawn automagically. You should stop it by "stop mpdecision" on a terminal (as su).

And most important of all

: If you use some kind of in-kernel hotplug driver, you should really disabled mpdecision ! Else you'll end up having 2 concurrent drivers trying to handle hotplugging with different logics, which will result in potential pretty erratic behaviour (hotplug wise).

CPU controlling apps

:

Some try to lock access to scaling min/max to allow you to limit the CPU freq. to your liking. To do this, those apps change the filerights to scaling min/max (from rw-rw-rw- to r--r--r--).

While it does work, if you use mpdecision, you'll cut off part of its purpose, because it will be transformed into a "simple" hotplug driver, but won't be able to do its work as frequency scaling aid. As such I don't find that a very good idea, but it works.

That's why I implemented a CPU hardlimit in my kernel, which will accept what mpdecision requests, but only withing the limit you set, instead of just refusing all input from it.

-----------

I hope I could shed some light on this CPU topic ;)

JP.