[myTouch 4G Android Development] thederekjay:
INFO​

BFS (Brain **** Scheduler):

BFS: The objective of BFS, compared to other schedulers, was to provide a scheduler with a simpler algorithm, that did not require adjustment of heuristics or tuning parameters to tailor performance to a specific type of computation workload. The BFS author asserted that these tunable parameters were difficult for the average user to understand, especially in terms of interactions of multiple parameters with each other, and claimed that the use of such tuning parameters could often result in improved performance in a specific targeted type of computation, at the cost of worse performance in the general case.[4] BFS has been reported to improve responsiveness on light-NUMA (non-uniform memory access) Linux mobile devices and desktop computers with fewer than 16 cores.

Information Source: http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler & http://ck.kolivas.org/patches/bfs/bfs-faq.txt

Swap:

Swap: Swap is a way to extend your physical memory. The OS moves the less accessed memory pages to slower, and cheaper storage medium. This frees up RAM for things that require the speed.

Governors:

demonspeed! Governor: this governor is rather similar to the 'ondemand' governor both in its source code and its purpose, the difference is its optimisation for better suitability in a battery powered environment. The frequency is gracefully increased and decreased rather than jumping to 100% when speed is required. Based off a lag free concept, with screen off profiles built in. demonspeed has not been tested against battery life performance, but rather for speed and user interaction.

[*]SuperBad Governor: A "superbad" super smooth rendition of a highly optimized "smartass" governor! Low latency and more responive to the user.

[*]SCARY Governor (@Scaryghoul): Scary - A new governor Scaryghoul wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.

I/O Schedulers:

V(R) I/O Scheduler: V(R) is similar to, and based on, Linux's deadline I/O scheduler. It implements request deadlines which try to limit starvation, but provide no hard guarantee of request latency. It also merges and batches requests in a similar manner, but unlike deadline, read and write requests are issued together. This means there is no preference to reads over writes. Thus, higher throughput can be achieved at the cost of interactive performance. Secondly, V(R) could be used for situations where maximal throughput it the primary concern, such as batch processing systems, where per-request latency is not important. By scheduling read and write requests together and setting sufficiently high deadlines, V(R) can theoretically produce a better schedule than deadline, AS or CFQ.

RCU SubSystem:

Tiny Preempt RCU: This implements a small-memory-footprint uniprocessor-only implementation of preemptible RCU. This implementation uses but a single blocked-tasks list rather than the combinatorial number used per leaf rcu_node by TREE_PREEMPT_RCU, which reduces memory consumption and greatly simplifies processing. This version also takes advantage of uniprocessor execution to accelerate grace periods in the case where there are no readers. The general design is otherwise broadly similar to that of TREE_PREEMPT_RCU.