Develop Bugs

How to configure the standard kernel scheduler (CFS) to behave more like BFS

First an introduction (sorry, if this got a little long, just wanted to make clear for everybody what we are talking about).
What is a scheduler?
The scheduler is a built-in part of the Linux kernel. It is that part of the kernel which decides how the available cpu power is divided among all running processes. As the cpu can only work for one process at any given time, the scheduler is responsible to assign cpu time-slices fairly to running processes.
Because of this the scheduler (among other things) plays an essential role on how responsive a system "feels" for the user. That's because responsiveness depends among other things on the time how long it takes from user input until the cpu handles the input (i.e. until "your" task/process gets cpu-cycles).
Current state of the art:
The standard Linux kernel uses the so called "Completely Fair Scheduler" (CFS) since some time (October 2007) now and seems to be useful for most use-cases (server, desktop, smartphone..).
As you may have already heard, since August 2009 there is a new player on the field, namely the "Brain **** Scheduler" (BFS). BFS promises some better latency behaviour on smaller platforms with fewer cpu-cores and mobile devices. Altough it wasn't accepted into the official Linux kernel tree, it was used by cyanogen and also adopted by Google into the mainline Android kernel (and as we are having kernel sources now, I'm sure you will see some more BFS-enabled kernels for the Hero, too).
But back to topic:
So, what I am going to talk about applies to those of you who DON'T have a kernel with the BSF scheduler (i.e. which have the standard CFS scheduler) which should be the majority of ROMs at the moment.
Tuning the CFS scheduler:
Even it's said that BFS may be better for small devices it's also possible to configure CFS for our needs:
While searching around I learned that the behaviour of the CFS scheduler can be influenced at runtime by a few parameters. All these settings can be applied at runtime and will be gone after a reboot. So it is safe to play around a little bit.
One interesting parameter I found was "NO_NEW_FAIR_SLEEPERS". As stated by some people on the Linux kernel mailinglist :
NO_NEW_FAIR_SLEEPERS is something that will turn the scheduler into a more classic fair scheduler (like BFS is too)
Click to expand...
Click to collapse
If this is true, maybe it will let the CFS behave better optimized for small devices.
But let's try it out! Let's see if it gives us some improvements.
How to to this:
Code:
# Step 1: Mount debugfs (which is a virtual filesystem like /proc/ or /sys/)
mount -t debugfs none /sys/kernel/debug
# Step 2 (optional): Display the current scheduler flags
cat /sys/kernel/debug/sched_features
# Step 3: Set the flag NO_NEW_FAIR_SLEEPERS
echo "NO_NEW_FAIR_SLEEPERS" > /sys/kernel/debug/sched_features
# Step 4: Unmount debugfs again
umount /sys/kernel/debug
As said before: These changes are NOT PERMANENT. They will be gone after a reboot. But therefore it's safe to play around here.
Testing:
Tuning the scheduler will not give you plain speed improvements, so testing with Linpack is useless here. Instead it changes the way how the system reacts if there is a lot of multi-tasking.
So when you have changed the settings try testing around a little bit when the system is under load (like playing music while doing CPU intensive stuff or things like that) and report if it behaves better/worse than with default settings.
How to undo the setting:
Simple reboot your phone.
Or redo the steps above and replace the command in Step 3 with this one (note that the prefix "NO_" is ommited here):
Code:
echo "NEW_FAIR_SLEEPERS" > /sys/kernel/debug/sched_features
Feel free to test and share your findings!

I guess I can copy paste the lines and use GScript to run them.
Any way to make this permanent? Put something in init.d maybe?

Geochelone said:
I guess I can copy paste the lines and use GScript to run them.
Click to expand...
Click to collapse
Of course. You will find 2 scripts for gscript in the attached zip-file:
enable_CFS_tweak.sh
disable_CFS_tweak.sh
So you can simply switch for easy testing.
For those who don't know GScript: It's an app from the market to easily execute scripts on your phone. Pretty handy if you are testing things before you add them to an init-script.
Instructions:
Install "GScript Lite" from the market
Unzip the 2 scripts and place it on the sd-card into the folder gscript
Launch GScript Lite, press "Menu" -> "Add script" -> "Load file" and select the scripts you just placed into "gscript" folder.
Make sure the "Need SU?" checkbox is checked and press "Save"
Tap on the script to launch it.
Geochelone said:
Any way to make this permanent? Put something in init.d maybe?
Click to expand...
Click to collapse
Correct. You would need to place the commands into an init script, which are located in "/system/etc/init.d" on most ROMs.

Hard to test..
I underclocked my Hero to 245Mhz, started the music player, launched NeoCore benchmark and via adb launched 10 instances of "md5sum /dev/urandom".
Music still not choppy. No matter whether the tweak is enabled or disabled.
The scheduler seems too good to exploit it..
[edit]
just got a NeoCore benchmark if 02.8 FPS Yeahh, that's stresstesting..
[/edit]

is there a way to make this by default in the source?
maybe add the option to the .config file?

MaXo64 said:
is there a way to make this by default in the source?
maybe add the option to the .config file?
Click to expand...
Click to collapse
Yes, you can edit kernel/sched_features.h
and replace
Code:
SCHED_FEAT(NEW_FAIR_SLEEPERS, 1)
with
Code:
SCHED_FEAT(NEW_FAIR_SLEEPERS, 0)

thanks mate, compiling right away..

what is the test result?

Just so you guys know we are basically doing this now on the Eris... via some cool scripts:
http://forum.xda-developers.com/showthread.php?t=784089&page=7

Thanks for the tip will definitively check it out

Wow! Thanks for the tip. After reading it sparked my curiosity in the Linux kernel so I went hunting on the web for more detailed info on this particular parameter (NEW_FAIR_SLEEPERS) but I found no useful info as to what exactly it is or what it does. unfortunately, the name doesnt give too much away either (to the layman).
Anyway eventually I came across a site that a couple of other SLEEPER parameters are mentioned. and it claimed that tweaking these as well as changing the sched_latency and sched_granulairty parameters will enhance android phone performance. Again I searched for explanations of these parameters but to no avail (im obviously not very good at searching!). In the end I thought id just apply the tweaks and see what happened. and voila! the phone is the smoothest I have ever felt it!
As I said I dont know which tweak is responsible for the smoothness or if its just a combination of all three but my phone is really nice to use now. I can scroll long lists and actually see scrolling instead of a stutter from start to finish! I am running elelinux 1.8 and flykernel10a at 528MHz and its smoother than i've had it when running at > 600MHz.
I have no idea what implications the changes have on the overall performance of the phone but its smooth and not overclocked! cant be bad??
so heres the changes I applied: (from ./adb shell or terminal emulator on phone)
$ su
# mount -o remount,rw /system
# echo 'kernel.sched_latency_ns = 600000' >> /etc/sysctl.conf
# echo 'kernel.sched_min_granularity_ns = 400000' >> /etc/sysctl.conf
# echo 'kernel.sched_features = 24188' >> /etc/sysctl.conf
# mount -o remount,ro /system
# sysctl -p
kernel.sched_latency_ns = 600000
kernel.sched_min_granularity_ns = 400000
kernel.sched_features = 24188
# exit
$ exit
the 24188 parameter disables a couple of sleepers and the other two change some timings in the kernel. The changes are supposedly ONLY suitable for non-BFS kernels. but they are supposed to make the CFS kernel behave more like the BFS kernel in general.
Anyway try it and see if you want and report back if it makes your phone any better or worse. Or if there are any Linux gurus maybe you can shed more light on what these parameters actually do.

I know this thread is a little old, but I wanted to report that those settings worked great on my MyTouch Slide! I'm also overclocked/underclocked to 825/245 and using the autokiller memory optimizer, with the settings you suggest my phone is amazingly fast!
I did a little research on these settings as well, and will report back as I do some more testing to see what works best with the specs in this specific phone. At that time I will post a link to a new thread on this in the section for my specific phone.
Thanks for the great tips!

activity manager cpu 100%

Hi
i have a weird thing , dont know if its rom related but defenetly noticed it after rooting my device and installing cosutm roms. well i only used ARHD since 2.0.09 and i love it.
but , what happens is that suddenly and out of nothing (after like hours/days and the rom running smooth and ultra fast) , system cpu usage jumps to 100% and never bugs off only through a restart, and this seems to happen with all the different versions of ARHD i had, even though i install most of them with full wipes. but this i don't understand and it annoyes me cos it uses this cpu amount and drains battery and it happens suddenly and randomly , dunno what triggers it, and no matter how i tried to track it to see the error but couldn't find a thing.
i just hope u can help me by taking a look at this log i saved from android systeminfo app registering some errors (3 min log and it drained 14% battery ) , it shows something about "activity manager", im not a developer and i know nothing about those codes, but would be awesome if someone helps me out with any tip please.
thank you.

I am not a DEV but i don't think your log file includes any clue of what is causing your problem. Do you have sense account on? or any types of account that let you track your phone?

Activate usb debugging
Seems to be the bug with the .init process.
Sent from my Desire HD using Tapatalk

thank you for the replies , i already have usb debugging on. dunno what is causing this, its totally random and its driving me nuts.

can you see a process that uses 100% cpu in android system info? If yes, try to kill it and look at your cpu usage.
CPUNotify is a great tool. It shows cpu usage in the notification bar
Sent from my Desire HD using Tapatalk

the process showing 100% cpu usage (not always but randomly, no idea what triggers it ) is system , and u can't force close or end that task

Hmm strange... i can't even find a process called activity manager on my phone...
Well i don't know but maybe it's related to the DroidDream malware. Some apps in the market were infected with this virus. And i've read that the virus gains root access and can download other apps in the background.
Here's a link: http://forum.xda-developers.com/showthread.php?t=977154
I really don't know if it's related to this but it just came to my mind
Sent from my Desire HD using Tapatalk

thx for the help mate , but i dont think its related to droidream cos ive been having this issue since a while (long time before droidream was up )
im still monitoring to find out what is causing this issue.

i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
Activate usb debugging
Seems to be the bug with the .init process.
Click to expand...
Click to collapse
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.

wow , cheers mate for the help , sounds a bit complicated for me but at least we know what it is now and how to get over it.
but how come mike1986 doesnt know about this bug and its fix ? he could incorporate this into his next build so it saves us that command run every 15 mins. or it cant be incorporated ?
someone should tell him to be honest
but cheers for explanation mate, thank you

Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.

walda said:
Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.
Click to expand...
Click to collapse
i have no idea about that , if he does then im sure he will fix it

As I read in mikes 3.0 thread, he is informed. Fine...
sent from my DHD via Tapatalk

further to this.
in ProcessStats.java (im not sure if this is a kernel file or if it sits just outside the kernel).
mBuffer looks to me to be the main problem.
1. in apaches rom, which is overclocked he defines 23 CPU speeds..ProcessStats.java only allows 20
Code:
private long[] getCpuSpeedTimes(long[] out) {
long[] tempTimes = out;
long[] tempSpeeds = mCpuSpeeds;
final int MAX_SPEEDS = 20;
if (out == null) {
tempTimes = new long[MAX_SPEEDS]; // Hopefully no more than that
tempSpeeds = new long[MAX_SPEEDS];
this is a minor issue..as this overflow is trapped in the loop anyway:
Code:
if (speed == MAX_SPEEDS) break; // No more
however, the definition of mBuffer is too small:
Code:
private byte[] mBuffer = new byte[256];
my file at the moment is 300 bytes. the readFile reads only once instead of looping until end of file:
Code:
int len = is.read(mBuffer);
is.close();
so only the first 256 bytes are ever read.
My assumption is that IF the files first 256 bytes ends up cutting off the last read line (and that line lies in the first MAX_SPEEDS lines of the file) before the speed time element..this causes a NoSuchElementException to throw..as the last line will be like
921600 255
960000 750
998400 8042
10368
ie the line
1036800 3089
was cut off too soon and this code
Code:
long val = Long.parseLong(token);
tempSpeeds[speed] = val;
token = st.nextToken(); <-- here
val = Long.parseLong(token);.
in getCpuSpeedTimes() fails as it cant see the timing?
would then fail on the second nextToken().
the big question is who owns that code in our custom ROM? is it the same as the original android code so we are at the mercy of Google to fix it or is this something Mike / Apache will be able to patch up ..assuming i'm making sense
the only workaround is as i said before: to chmod this file to 700 and ensure it stays there (avoid using setcpu as it changes the permissions).
You can probably also reduce this by limiting the CPU frequency range your phone uses (ie keep the filesize smaller)..if you have profiles that span 200mhz to 1.2ghz then you will probably hit this sooner
i did a test.
1. rebooted my phone..ensured time_in_state had permissions -r--r--r--
2. manipulated CPU frequency using cpu tuner to make all frequencies have at least 5 bytes per line.
once the first 20 lines were > 256 bytes and the 256nd byte sat between <cpu speed> and <time spent at that speed> i get the loop.
eg just before the issue arose i saw:
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 9937
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
i had my cpu pinned to 960 mhz.
the 256 at this point lies here:
Code:
1075200 1560
1113600 1
ie line 20 is cut off after 1..this is still "valid" in terms of the data in mBuffer..but once 960 rolled into five digits
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 10288
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
the 256 byte now meant the last line shifts to:
Code:
1036800 6864
1075200
the 2nd word is now totally missing!
as soon as this happened..my logcat started issuing
Code:
Unexpected exception collecting process stats
java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(StringTokenizer.java:272)
at com.android.server.ProcessStats.getCpuSpeedTimes(ProcessStats.java:596)
at com.android.server.ProcessStats.getLastCpuSpeedTimes(ProcessStats.java:568)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1657)
at com.android.server.am.ActivityManagerService$4.run(ActivityManagerService.java:1583)
errors.
something later on then causes this behavior to go into a full tight loop (as once the issue starts..it just issues this every few seconds..so most uses wont notice it).

didnt mike fixed it with his latest release (ARHD 3.1) ?

Goodm7sn said:
didnt mike fixed it with his latest release (ARHD 3.1) ?
Click to expand...
Click to collapse
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).

DazzaL said:
i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.
Click to expand...
Click to collapse
Thanks mate, your solution is really effective on my DHD with revolution 3.0.
I am going to reflash with revolution 3.1, hopefully 3.1 will cure the cpu 100% usage

im on android revolution HD and i can confirm this , 100% system cpu of death is still here, didnt get fixed , had to change setcpu frequency and it stopped
meh phone cant last 12 hrs without a restart, frustrating.

DazzaL said:
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).
Click to expand...
Click to collapse
if setcpu changed the range once the gui is opened , what do u recommend us to use for overclocking ? something safer
thx for helping

I read that it happens with CPU tuner and even without anything also!
The only solution I see is to fix the frequency file.
sent from my DHD via Tapatalk

Adjusting the "Touch Slop" in CM9 (from 8 to 16)

I responded in the larger CM9 thread but it will probably be buried in a day or so. And I think this will help devs who are working on CM9 builds at the moment.
------------------------------------------------------------------
jdommer said:
The correct settings for the our touch screen appear to be:
Code:
touch.deviceType = touchScreen
touch.orientationAware = 1
# Size
# Based on empirical measurements, we estimate the size of the contact
# using size = sqrt(area) * 28 + 0.
touch.size.calibration = default
touch.size.scale = 1
touch.size.bias = 0
touch.size.isSummed = 0
# Pressure
# Driver reports signal strength as pressure.
#
# A normal index finger touch typically registers about 80 signal strength
# units although we don't expect these values to be accurate.
touch.pressure.calibration = none
touch.pressure.scale = 1.0
# Orientation
touch.orientation.calibration = default
Unfortunately, that doesn't do anything for the tap/drag problem. The KF can't distinguish pressure or size of touch.
Looks like Android decides any touch where x1-x2 or y1-y2 > 8 as a drag. I can't find any place that that value is configurable after scouring the internets all morning, but if it could simply be turned up to maybe 12 that would probably alleviate 90% of our taps as drags problems.
Anyone have any idea, is there a config file or is that compiled in and has to be changed at source? I feel competent enough to dink with config files, but can't compile crap.
Click to expand...
Click to collapse
I build from the KFire-Android git as a testing model and i've been experimenting with a setting of "16" for touch slop, and in my opinion it's working much better.. could probably be 12, but who knows. I'm having a much easier time selecting things like Beautiful Widgets 1x1 Toggles, where before it was a trial of patience and about 10 touches.
This is a setting in the overlay config.xml file. I went ahead and committed it this morning to the KFire-Android org at Github:
https://github.com/KFire-Android/device-amazon-otter/commit/56b3d52fe6c645a18e60ab765e5b9831cb6a0663

Is the code that uses the clickSlop in android hackable for KFire?
I found on my device that most of the noise on taps was occurring in the last few samples (like the touchscreen firmware is averaging in some bad samples on finger release) and that by dropping the last few touch events I got much better touch response in my app. I'm not sure where to put such a state machine in the framework, though, or how to have it only for KFire...
(My state machine would buffer 3 samples ahead for the first 20 samples, and then drop the last 3 samples on finger up and patch N-3 to be a finger up instead of a move -- after 20 samples it just passed everything through with no buffering to avoid adding latency to drags).

[DEV][KERNEL] Tegra3 power management notes and tricks

This thread contains findings on how to view and set kernel parameters related to power management. Although there is no kernel source for One X, some information can be obtained from Transformer Prime kernel sources (also a Tegra 3 device), and from the device itself via sysfs interface.
sysfs files related to CPU power management:
/sys/kernel/debug/tegra_hotplug/max_cpus - maximum CPUs to use. User-configurable, default 4. This is not touched by the Android OS, and will remain in whatever state we set until reboot.
Set this to "1" to make the phone a lot less power-hungry and overheating.
At the cost of performance, of course.
*NOTE: second core will activate sometimes if this is set to "1", but 3rd and 4th cores are disabled for sure.
/sys/kernel/debug/tegra_hotplug/min_cpus - minimum number of CPUs to use.
This _is_ touched by the OS, and can not be set reliably.
/sys/kernel/debug/tegra_hotplug/stats - time each core spent active. Including 5-th "low-power" core.
e.g.:
Code:
cpu: G0 G1 G2 G3 LP
transitions: 26 12 0 0 25
time plugged: 3110 1222 0 0 95122
time-stamp: 4296183486
/sys/kernel/debug/cpuidle/lp2 - another stats interface.
/sys/module/cpu_tegra/parameters/cpu_user_cap - Max frequency cap for all cores. Default 1500000 (1.5GHz), can be set to any lower value to underclock.
But it is often set by the OS different values (most frequently, back to it's maximum). Maybe, changing this string in libhtc-opt2.so via hex editor can prevent system from changing it?
/sys/kernel/cluster/active - currently active CPU cluster. "LP" for low-power core, "G" for generic (normal) cores.
Can be changed manually, but is also modified by the system at will.
All above values can be changed from root shell via "echo 'value' > /sys/path/to/file"
Maybe, this will come handy to some ROM or CPU-monitoring app developers.
References:
Asus Transformer kernel source
[DEV] Enable 2D GPU rendering in HTC One X & about build.prop tweaks
some findings by phirenz

is there any way to request more use of the companion core?

In case anyone's wondering, I just found out that /sys/kernel/cluster/active must be opened as root even for reading; opening the file as any other user will not succeed.
The other files seem to allow reading as a standard user, however.

It woulod be great is someone created an app for setting number of CPUs. It is useful sometimes to set it to 1 when you are traveling and want to get max possible battery.
It would be even better if it was possible to disable all 4 cores and force system to use LP core only. It would be brilliant max power saving mode.

I've modified OS Monitor to support Tegra 3's stuff (temperature, number of cores and determining whether it is low power/general CPU in use) and my experience is that there's no or very little battery gains to be had because the other 3 cores are off most of the time anyway (when idle)
I'm using stock 1.28. The low power core doesn't seem to like being activated for more than a few seconds at a time, too.

I've modified OS Monitor to support Tegra 3's stuff
Click to expand...
Click to collapse
Can u share the apk here...xD???

thanks to the OP.....I don't have a One X but this info helped me to force all 4 cores of my Asus TF300T go online and offline as i wish.

schriss said:
It woulod be great is someone created an app for setting number of CPUs. It is useful sometimes to set it to 1 when you are traveling and want to get max possible battery.
It would be even better if it was possible to disable all 4 cores and force system to use LP core only. It would be brilliant max power saving mode.
Click to expand...
Click to collapse
use core control or francos kernel updater works for every custom kernel also stock kernel and you can choose how many cores...but battery life is not better with deactivated cores and soemetimes even worser -.-

I used to be able to do this, but now I'm using n3o kernel and I can't find the tegra_hotplug folder inside sys/kernel/debug. Help?

joeystar said:
I used to be able to do this, but now I'm using n3o kernel and I can't find the tegra_hotplug folder inside sys/kernel/debug. Help?
Click to expand...
Click to collapse
Man ask this in kernel thread not here....-.-
Sent from my HTC One X using xda app-developers app

[KERNEL] Bricked-Kernel Hammerhead | Sweep2wake | KnockKnock/Dt2w

Welcome to the most customizable N5 kernel on xda
Bricked-Kernel Nexus 5 (hammerhead)​
Features:
* Based upon Google's msm 3.4 source
* Various fixes, improvements and optimizatios (look @ github)
* Compiled with gcc4.7.2 toolchain (linaro 09.12)
* -O3+ optimized
* Snapdragon & CortexA15 optimizations
* replaced qcom's hotplug binary with msm_mpdecision (IN-KERNEL, better battery life + performance)
* Extensive sysfs interface for mpdecision with all the tuneables you want (/sys/kernel/msm_mpdecision/)
* replaced qcom's thermal binary with my IN-KERNEL solution. (/sys/kernel/msm_thermal/)
* export krait version to: /sys/kernel/debug/krait_variant
* Allow OC up to 2,5Ghz
* Allow UC to 96Mhz
* Undervolting (faux123)
* F2FS Support
* Multirom Support
* KCAL (savoca) & Gamma Control (faux123)
* Sound Control (faux123)
* Default clocks: 300 Mhz min & 2265,6 Mhz max
Zip features:
*** ON-THE-FLY-RAMDISK EDITS!
*** THIS KERNEL USES YOUR RAMDISK, it will just modify it on the fly while flashing. These changes are not creating any incompatibilities with roms/other kernels.
* removes min freq overrides from the ramdisk
* removes governor overrides from the ramdisk
* adds init.d support to your ramdisk (if not already supported)
* modifies stock ondemand settings
* add module insertion
Check the compare links for the rest ​
Where is tha Changelog???
There will be no more changelogs.
Instead the download pages were outfitted with compare links to github for each download.​
What is sweep2wake?
Disabled as default, activate through an app like KControl or over sysfs: echo 1 > /sys/android_touch/sweep2wake​
What is doubletap2wake / knock knock?
Disabled as default, activate through an app like KControl or over sysfs: echo 1 > /sys/android_touch/doubletap2wake​
How to install?
Flash through recovery. #done.​
How to uninstall?
Flash this:
http://bricked.de/downloads/kernel/hammerhead/bricked_uninstaller_hammerhead.zip
You are done. Bye.​
Where to complain about errors/bugs?
Please use the Issuetracker for bugs/errors/feature wishes!
Issuetracker @ https://github.com/showp1984/bricked-hammerhead/issues
[email protected]
IRC Chat: Freenode IRC #bricked​
Download:
No Guarantees! If it kills your grandmother or your device, I am NOT responsible! If you understand this:
(If you download, please hit Thanks below my post! Thank you!)
>>> DOWNLOAD <<<​
Donation Hall-of-Fame:​
> Hall of fame <
Thank you very much!​
Stock 4.4 Nexus5 boot.img - flash this if you come from another kernel coming with it's own ramdisk (eg: zip contains a *.img file) ONLY FLASH ON 4.4
Source:
​

What is msm_thermal?
Kernel based 3-phase thermal control!
This replaces your /system/bin/thermal-engine-hh binary which is renamed by the installer to thermal-engine-hh_bck.
It will throttle your cpu speed to keep it cool and unleash it if the cpu has cooled down enough. (3 phases: low, mid and high)
Check /sys/kernel/msm_thermal/conf/ for the thermal configuration
allowed_max_high = highest threshold (phase 3)
allowed_max_low = remove the throttling if we cooled down to this (clr_thrshold)
allowed_max_freq = max frequency if throttled (limit)
[...]mid[...] = same as above, just for phase 2
[...]low[...] = Lowest threshold (phase 1)
check_interval_ms = how often shall we check? (sampling rate)
shutdown_temp = if we reach this shut down the device!
If you want to see msm_thermal doing it's job:
Code:
adb shell
cat /proc/kmsg | grep 'thermal'
What is msm_mpdecision?
100% kernel based multi core decision! (should cpu1/2/3 be online or not?)
This replaces your /system/bin/mpdecision binary which is renamed by the installer to mpdecision_bck.
Check /sys/kernel/msm_mpdecision/conf/ for the configuration.
startdelay = time until mpdecision starts doing it's magic (20000)
delay = time between checks (130)
pause = if something else plugs in the cpu, fall asleep for 10000ms (10 secs)
scroff_single_core = if the screen is off, don't plug in cpu1/2/3. Additionally: Unplug all cpus except cpu0 when screen is turned off (1)
enabled = enable(1) or disable(0) mpdecision. This does not affect scroff_single_core!
min_cpus = min cpus to be online, cannot be < 1. Default: 1
max_cpus = max cpus to be online, cannot be > 4. (if you set it to 2 and min_cpus to 1 you will basically have a dualcore) Default: 4
idle_freq = a value against that will be checked if a core +/- is requested. (499200)
If cpu0 is below that value and a core up of another cpu is requested, nothing will happen.
If any other cpu is above that value and a core down of that cpu is requested, nothing will happen. (otherwise it would now put down that cpu even though it is still working, which isn't what we want)
Hot plug thresholds (aka now it gets 'complicated')
This small formula calculates which value will be used: (number_of_cpus_online - 1) * 2
The result of this formula will be the nwns_threshold where a new cpu is hotplugged.
The result of this formula + 1 will be the nwns_threshold where a cpu is unplugged.
nwns_threshold_x = runqueue threshold, if this is reached cpuX will be hot/unplugged
twts_threshold_x = time threshold, this amount of time must have passed for the related action to be taken (hot/unplug)
Example:
One cpu is online.
(1 - 1) * 2 = 0 ergo:
nwns_threshold_0 = cpu1 will be hotplugged at this value
((1 - 1) * 2) + 1 = 1
nwns_threshold_1 = cpu0 will be unplugged at this value
Since we can't unplug cpu0 this is '0'.
Two cpus are online.
(2 - 1) * 2 = 2 ergo:
nwns_threshold_2 = cpu2 will be hotplugged at this value
((2 - 1) * 2) + 1 = 3
nwns_threshold_3 = cpu1 will be unplugged at this value
etc...
Some values are:
NwNs_Threshold: 12, 0, 25, 20, 32, 28, 0, 35
TwTs_Threshold: 140, 0, 140, 190, 140, 190, 0, 190
Where the position and function of the number equals the result of the above explained formula.
(all times are in ms)
If you want to see the mpdecision magic happening:
Code:
adb shell
cat /proc/kmsg | grep 'MPDEC'
mpdecision's input event boost, aka project butter
This will boost your min cpu speed if you touch the screen or press a button and gives you full control.
In those events the min cpu freq will be risen to a predefined value (look below) on every online cpu. This boosts overall reaction times and smoothness a lot. (works similar to the qcom mpdecision binary)
Configuration files:
[email protected]:/sys/kernel/msm_mpdecision/conf # ls | grep boost
boost_enabled
boost_freqs
boost_time
All of them work like the usual sysfs files, except one special case:
boost_freqs will list all frequencies from cpu 0 to cpu x. Cpu 3 and any following cpu will share one frequency.
To change those frequencies echo the cpu number + the frequency in khz.
Example: To change the boost freq of cpu3 (and 4,5,6,7,8, etc) the echo would look as follows:
Code:
echo "3 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
for cpu0:
Code:
echo "0 960000" > /sys/kernel/msm_mpdecision/conf/boost_freqs
Defaults:
Code:
cat /sys/kernel/msm_mpdecision/conf/boost_freqs
960000
960000
729600
576000
Why do I have no WLAN?
Due to this kernels very high optimization settings it is too big for our boot.img with WLAN included into the kernel, so it is built as a module. That means it needs to be inserted into the kernel upon boot up, which needs to be automated for maximum comfort.
The zip adds module insertion to your ramdisk, if that fails for some reason the wlan module cannot be inserted.
if
Code:
adb shell lsmod
doesn't show this:
Code:
tun 14701 0 - Live 0x00000000
cifs 275399 0 - Live 0x00000000
bcmdhd 2964650 0 - Live 0x00000000 (C)
Then something went horribly wrong.
Chances are that I broke it and this should never happen.
One post in the issue tracker will probably fix it with the next release
You can restore wlan for your current bootup by executing:
Code:
adb shell
su
insmod /system/lib/modules/bcmdhd.ko
Is there an app available to customize this pure bodacious and awesome kernel?
Yes there is: KControl. It's in the Google Playstore.
​

A few benchmark results:
Vellamo Metal:
http://vellamo2.quicinc.com/api/v2/app/plot/Metal/submission/PEE3B604B-8C49-69F5-001E-6BCA76DF491D
(usually ranges from 11xx-12xx. Depending on system background load, thermal status, air pressure, weather, world hunger, etc...)
Antutu:
https://plus.google.com/u/0/108262968419038009038/posts/VJbxpMoFJPN
(usually ranges from 28.xxx - 30.xxx. Depending on system background load, thermal status, air pressure, weather, world hunger, etc...)
3DMark Icestorm unlimited: (the others are maxed out)
https://plus.google.com/u/0/108262968419038009038/posts/N24t9ssoBcL
(17xxx)

FIRST! o yes!!! mwhahahah!! and so it begins

Finally a Bricked thread! :victory: No more F5 spamming the kernel website

Good stuff, you've finally joined the party.
Sent from my Nexus 5 using Tapatalk

Woot! first page!

+1
10 char

Ngo93 said:
Finally a Bricked thread! :victory: No more F5 spamming the kernel website
Click to expand...
Click to collapse
If you are familiar with rss, all kernel download pages have a little rss symbol, if you click it you get here:
http://bricked.de/kernelrss.php?action=krss&device=hammerhead&release=stable&type=aosp
Just something to consider instead of spamming F5
unforgivenmercy said:
Good stuff, you've finally joined the party.
Click to expand...
Click to collapse
If you take a look at the dates on my homepage you might notice that the party ended about 2 days ago. The after party on the other hand starts now!
faux123 said:
Woot! first page!
Click to expand...
Click to collapse
Indeed! Well the thread isn't that old yet

OBI ONE is here aweseome !!! Always a pleasure to hang around in ur threads

n3ocort3x said:
OBI ONE is here aweseome !!! Always a pleasure to hang around in ur threads
Click to expand...
Click to collapse
left something on github for you

I saw, many thanks for that, but i think i have to ask u a bit about this, already in bed now, but tomorrow is another day 5star and subscribed as always

show-p1984 said:
left something on github for you
Click to expand...
Click to collapse
In the op it just says to install. So no wiping of cache or D cache correct? Sorry just re assuring
Sent from my Nexus 5 using Tapatalk

Wiping cache is redundant and you don't have to do it with kernels.
Sent from my Nexus 5 using Tapatalk

Carbajal3009 said:
In the op it just says to install. So no wiping of cache or D cache correct? Sorry just re assuring
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
The zip does it for you.
However, if it gives you a warm and fuzzy feeling you are free to do it again (so twice then ^^).

Wow, finally it is here. Flashing now.

Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?

jazzor said:
Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?
Click to expand...
Click to collapse
A fair question, I imagine there is something sacrificed using either or.
Sent from my Nexus 5 using XDA Premium 4 mobile app

jazzor said:
Has anyone actually demonstrated (scientifically or otherwise) anything wrong with the qcom mpdecision binary? Im not taking anything away from kernel developers who write their own mpdecision (especially those who also provides sources), but I am curious as to whether they are actually better than those provided by qcom. Surely they know more about the capabilities of their own cpus better than anyone no?
Click to expand...
Click to collapse
It's not that complicated (there is no black voodoo magic), that's why bricked kernel was the first to introduce this feature back on the pyramid.
CPUs need to be plugged in / unplugged based on load, there is nothing more qcom can know that we can't also see inside of the kernel.
There is one HUGE thing that is wrong with qcom's mpdecision: It's closed. It's a black box. We don't have any idea what is going on in there. Literally, none. It's not even configurable. It could contain secret nsa code, or send dirty sms to your girlfriend (who might actually enjoy that, idk...)
If we would have source, hell, awesome. I wouldn't have spent over a year (first commit: Date: Thu, 21 Jun 2012 06:06:47 +0200, see here) to get my msm_mpdecision solution to the point where it is a) awesome and b) a lot better than the binary. It can be configured in any way you might need to. It features statistics on how often and how long a cpu is hotplugged. It has the input event boost. It's the full package deal.
If you compare my kernel with the stock kernel you will see huge performance improvements and battery savings on bricked. Those are not only because of my msm_mpdecision but certainly related. Furthermore: we can completely customize it, over sysfs, on a running kernel, without reflashing.
That's what I would have expected from qcom in the first place.
Another thing wrong with qcom's binary: It's static. Meaning: If you change your min freq on stock it will always reset back to defaults. Same with their thermal binary. That's just annoying.
msm_mpdecision will notice it if you change your min frequency and dynamically work with that from there on. It will also prevent hotplug wars between apps and it: eg: an app plugs in cpus to grab some cpu data (like frequencies, etc. That is only available if the cpu is plugged in). Qcom's mpdecision would now raise hell to keep that cpu unplugged, my msm_mpdecision just sits back and chills for 10 seconds to avoid those wars. (again, even that delay is fully configurable)
There are also a bunch of boring advantages as to why it is better to let something crucial to the system run in kernel space and not in user space, but that would most certainly explode the context of this thread by the factor of 4.
My solution is not inferior to that binary in any way, in fact it has been vastly superior in my testing up until now, otherwise I would a) improve it or b) ditch it. I don't keep around bad stuff just for the point of having it or because I wrote it. If it sucks I will say that and act accordingly.

Thanks for the very informative post. I suppose there are advantages in avoiding qcom's mpdecision. Though i'd like to point out that the Android framework (msm power HAL) does use some of the interfaces provided by the binary (see hardware/qcom/power/). With the nexus 4, this will spam a lot of stuff to logcat if you are missing this interface, not sure if this is the same with the nexus 5, but judging by the sources it seems it will. Maybe you could provide some notification about this side effect.
Similarly, this could apply to the thermal side of things as well.