[Hero, G2 Touch Android Development] erasmux:
First, let me say I am deeply sorry to open yet another thread on this subject. But I have made some investigations of my own and would like to make some clarifications which I think should not be buried on page 6 of some long thread....

This thread continues the discussion started by these threads:

http://xdaforums.com/showthread.php?t=689829

http://xdaforums.com/showthread.php?t=785988

From what I gather there about 5 different parameters which are purposed for tweaking:

- NEW_FAIR_SLEEPERS (default ON) - This is about the only parameter which I do feel some difference when disabling it (on Floyo 0.8) and for the worse. Hence currently I intend to leave it on.

- NORMALIZED_SLEEPER (default ON) - I found various recommendations to turn this off. I don't feel much difference but maybe there is a slight improvement. Currently I intend to turn it off.

- sched_latency_ns:

* Targeted preemption latency for CPU-bound tasks:

* (default: 20ms * (1 + ilog(ncpus)), units: nanoseconds)

*

* NOTE: this latency value is not the same as the concept of

* 'timeslice length' - timeslices in CFS are of variable length

* and have no persistent notion like in traditional, time-slice

* based scheduling concepts.

*

* (to see the precise effective timeslice length of your workload,

* run vmstat and monitor the context-switches (cs) field)

- sched_min_granularity_ns -

* Minimal preemption granularity for CPU-bound tasks:

* (default: 4 msec * (1 + ilog(ncpus)), units: nanoseconds)

- sched_wakeup_granularity_ns (not sure if this one was mentioned in previous threads but also related)

* SCHED_OTHER wake-up granularity.

* (default: 5 msec * (1 + ilog(ncpus)), units: nanoseconds)

*

* This option delays the preemption effects of decoupled workloads

* and reduces their over-scheduling. Synchronous workloads will still

* have immediate wakeup/sleep latencies.

Note the descriptions are from the kernel sources and default values are a bit different and also dependent on the init.rc in the ramdisk which is dependent on the ROM.

I tryed to play with the last 3 parameters in a very wide range and did not feel much difference. Based on my experience and searches over these forums and such I currently have these values:

sched_latency_ns 5000000

sched_wakeup_granularity_ns 1000000

sched_min_granularity_ns 1000000

They are somewhat arbitrary and if someone can bring up a scenario where the difference is noticeable I will happy to hear it.

Some technical notes:

- I have seen this "numerical" tweak in multiple places:

kernel.sched_features = 24188

This is not smart using a numerical value, as there are some new backports which I would like to incorporate into my kernel and they actually change the "correct" numerical value here.

The preferred way to tweak these settings was brought by androcheck here. Just a reminder:

# 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

I would actually skip the unmounting step since it doesn't bother to have it there and then you can play with the different parameters at /sys/kernel/debug directly.

I would like to emphasize my point about the kernel features tweaking, using an example with my current settings (only NORMALIZED_SLEEPER disabled):

# mount -t debugfs none /sys/kernel/debug

# echo NO_NORMALIZED_SLEEPER > /sys/kernel/debug/sched_features

# cat /sys/kernel/debug/sched_features | sed "s/ /\n/g"
NEW_FAIR_SLEEPERS
NO_NORMALIZED_SLEEPER
WAKEUP_PREEMPT
START_DEBIT
AFFINE_WAKEUPS
CACHE_HOT_BUDDY
SYNC_WAKEUPS
NO_HRTICK
NO_DOUBLE_TICK
ASYM_GRAN
LB_BIAS
LB_WAKEUP_UPDATE
ASYM_EFF_LOAD
NO_WAKEUP_OVERLAP
LAST_BUDDY

# cat /proc/sys/kernel/sched_features
24189

So I would highly recommend tweaking the sched_features only through the /sys/kernel/debug/sched_features where you actually know what you are doing.

Then to make it permanent you can grab the numerical value from /proc/sys/kernel/sched_features and write it, for example, to the sysctl.conf.

- One final technical note: f_padia in his post here detailed nicely how to make the changes permanent using sysctl.conf.

I find sysctl also very useful for temporary tweaking of the values, for example:

sysctl -w kernel.sched_latency_ns=5000000
sysctl -w kernel.sched_min_granularity_ns=1000000
sysctl -w kernel.sched_wakeup_granularity_ns=1000000

Alternatively you could also write them to the appropriate "file" at /proc/sys/kernel. Both these methods do not require the mount of the debug_fs but neither gives you the literal interface to the kernel features (which the debug_fs does - see above).