[Paid Software Announcement and Discussion] michelD:
Ok thanks for that and also for v1.3.2.

I think also that here could be a good place for the discussion of some of the tunable parameters via systune app. Indeed, I think that there should be no such big difference from ROM to ROM (but probably more from device to device...).

This offers also the possibility to give (and get) some information about the parameters that are tunable via Systune.

Among the different group of parameters, due to personal interest, I want to focus on scheduler ones (CFS and now BFS (since v1.3.2)).

And first of all, some theory, because before tuning anything, it is EXTREEMELY IMPORTANT TO UNDERSTAND the meaning of these parameters: here below is a partial copy of http://doc.opensuse.org/products/opensuse/openSUSE/opensuse-tuning/cha.tuning.taskscheduler.html about CFS in opensuse distribution.

NB: I am not an expert in Android, but IMHO I thing that even if Android runs on linux, it must be a lot of difference between running a phone and a desktop. It is why, it is interesting to have this kind of discussion here.

The comment are personal and are there just to start the discussion....

My phone is a HTC Desire HD, with blackIce ROM with LordMod UE kernel v8 CFS.

sched_child_runs_first

A freshly forked child runs before the parent continues execution. Setting this parameter to 1 is beneficial for an application in which the child performs an execution after fork. For example make -j<NO_CPUS> performs better when sched_child_runs_first is turned off. The default value is 0.

OK default value seems logical for me.

sched_compat_yield

Enables the aggressive yield behavior of the old 0(1) scheduler. Java applications that use synchronization extensively perform better with this value set to 1. Only use it when you see a drop in performance. The default value is 0.

OK default value seems logical for me, but Dalvik being a Java VM, 1 could also be logical ?????

Expect applications that depend on the sched_yield() syscall behavior to perform better with the value set to 1.

sched_migration_cost

Amount of time after the last execution that a task is considered to be “cache hot” in migration decisions. A “hot” task is less likely to be migrated, so increasing this variable reduces task migrations. The default value is 500000 (ns).

If the CPU idle time is higher than expected when there are runnable processes, try reducing this value. If tasks bounce between CPUs or nodes too often, try increasing it.

In case of single core processor, IMHO I think that this value must be set high....

sched_latency_ns

Targeted preemption latency for CPU bound tasks. Increasing this variable increases a CPU bound task's timeslice. A task's timeslice is its weighted fair share of the scheduling period:

timeslice = scheduling period * (task's weight/total weight of tasks in the run queue)

The task's weight depends on the task's nice level and the scheduling policy. Minimum task weight for a SCHED_OTHER task is 15, corresponding to nice 19. The maximum task weight is 88761, corresponding to nice -20.

Timeslices become smaller as the load increases. When the number of runnable tasks exceeds sched_latency_ns/sched_min_granularity_ns, the slice becomes number_of_running_tasks * sched_min_granularity_ns. Prior to that, the slice is equal to sched_latency_ns.

This value also specifies the maximum amount of time during which a sleeping task is considered to be running for entitlement calculations. Increasing this variable increases the amount of time a waking task may consume before being preempted, thus increasing scheduler latency for CPU bound tasks. The default value is 20000000 (ns).

For a phone running with a processor > 1GHz I thing that 5000000 is a good value (to be discussed further)

sched_min_granularity_ns

Minimal preemption granularity for CPU bound tasks. See sched_latency_ns for details. The default value is 4000000 (ns).

Same as above with a suggested value of 1000000

sched_wakeup_granularity_ns

The wake-up preemption granularity. Increasing this variable reduces wake-up preemption, reducing disturbance of compute bound tasks. Lowering it improves wake-up latency and throughput for latency critical tasks, particularly when a short duty cycle load component must compete with CPU bound components. The default value is 5000000 (ns).

Same as above with a suggested value of 1000000

sched_nr_migrate

Controls how many tasks can be moved across processors through migration software interrupts (softirq). If a large number of tasks is created by SCHED_OTHER policy, they will all be run on the same processor. The default value is 32. Increasing this value gives a performance boost to large SCHED_OTHER threads at the expense of increased latencies for real-time tasks.

IMHO must be sed = 0 for single core processor....

[To be continued later.....]