Im currently running an android phone and came across a website the other day where it suggested a few tweaks to the linux kernel to improve the performance of the OS. Without really knowing what the tweaks did I decided to apply them... and they worked! My phone was suddenly a lot smoother to use. So I thought it would be nice to know what the tweaks did and why they worked. Here are the tweaks:
I created a sysctl.conf file in /system/etc
then wrote the following lines to the file:
# 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
and thats it. Its quite obvious that the first two adjust some timings to do with the scheduler. But what exactly I dont know, I hope some can explain in as Layman terms as possible!
Also the final line disables NORMALIZED_SLEEPERS and GENTLE_FAIR_SLEEPERS i believe, but I dont know what this means! Im not sure what consequences this will have on the performance of the phone. All I know is that by applying these changes my phone is much smoother and I no longer need to OC it.
Any helps is appreciated. thanks
Short answer is that they are tweaks to the Linux "Completely Fair Scheduler" to improve performance on ROM-based kernels. Long answer is to Google "Completely Fair Scheduler" and start reading.
haha yeah well as I mentioned in my post I gathered they had something to do with tweaking the scheduler. I have read an awful lot about CFS and I still havent been able to understand what exactly the tweaks do hence asking on the this forum. I guess i'll have to wait to find out....
The scheduler is very complex, and makes this Mensa member's head hurt.
sched_min_granularity_ns sets the minimum preemption granularity timing. Too low and the system can thrash on task preemption, too high and the task latency can go through the roof as number of running tasks goes up. In the kernel code, this is normally set dynamically via algorithm, so the absolute setting is someone's notion of an optimization for the specific case. Not to say that their notion is wrong.
sched_latency_ns is tuning how long something can sit on the processor, as opposed to the previous setting which has to do with how fast it can get kicked off.
Basically, all this stuff is tuning for faster/higher volume task switching on the CPU, which tends to smooth things out on single user systems like cell phones and desktops, but quickly backfires as users/processes scale up, as with servers.
hmm thats interesting. so just to clarify. when you say task latency will go through the roof when 'the number of tasks goes up'. are the number of tasks things like having different apps running on your phone? is each app a single task or many tasks?
and what I sitll dont get is, how these times 'smooth things out'. I dont disagree that they do, I have seen the smoothening effect myself. But how?
will reducing the latency/granularity have the smoothening effect of increasing them?
perhaps if you could give an example it would be easier :D
thanks for you help
Normally an app is a single task, but this is not always like this. What is for sure is that each app is at least one task.
Originally Posted by f_p
There are two details to this situation:
Originally Posted by f_p
- The rarer the scheduler runs, the less resources goes to it and more resources go to the application you are running.
- When a user application gets to run, it runs for a longer time and has more chances to finish a round of interaction with you within a single quantum of processor time.
When thinking about this issues you should remember that your interaction with application usually includes two sequentially changing phases: you think, the application thinks. If the application is not able to finish thinking in a single turn of CPU access, it will have to wait some time until it gets to run next; only after two or more turns will it be able to give you response. In contrast, if the application normally finished all it has to do to respond within a single round of CPU access, you will perceive this as faster execution.
Note that in the first case, the other tasks run while you are thinking and you don't really feel it.
The dependency is not linear. Generally, these parameters should stay within certain bounds for the user to have the impression of smoothness. If the granularity goes too low, your system will thrash, as greyhairweenie says. This means that it will spend more time on switching between tasks than on actually executing them. If the granularity is too high, you will notice the effect immediately when you run more than one application. Indeed, the active application will be able to have the processor for a longer time per turn, but it will then have to wait until the other application(s) do their stuff, and, as you may guess, these other applications will each have a longer time to run. This means that your active application will be laggy and choppy.
Originally Posted by f_p
I hope that the cleverer guys here will underline my mistakes and explain them to us :-)
thanks for the additional info. I think I am getting a clearer picture of whats going on now.
However, I just read somewhere that one of the advantages of the CFS over older schedulers was the nanosecond accuracy it has with the high resolution timer. But then looking in sched_features I see that HRTICK (which i believe to be the flag for high enabling the high resolution timer) is disabled by default. If there is no HRTIMER than was does the scheduler fall back on? any ideas?