[Galaxy S I9000 Android Development] zibiksior:
ondemand

Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see "up threshold" in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed. - SetCPU website

OndemandX has to be some kind of ondemand scheduler;)

conservative

Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery. - SetCPU website

Interactive

The 'interactive' governor has a different approach. Instead of sampling the cpu

at a specified rate, the governor will scale the cpu frequency up when coming

out of idle. When the cpu comes out of idle, a timer is configured to fire

within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer

fires then we assume the cpu is underpowered and ramp to MAX speed.

If the cpu was not 100% busy, then the governor evaluates the cpu load over the

last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down

to.

SMARTASS

- is based on the concept of the interactive governor.

I have always agreed that in theory the way interactive works - by taking over the idle loop - is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the "old" minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.

Smartass will also cap the max frequency when sleeping to 245Mhz (or if your min frequency is higher than 245 - why?! - it will cap it to your min frequency). Lets take for example the 998/245 kernel, it will sleep at 245. No need for sleep profiles any more!

SmartassV2 (informal description and comparison with the first smartass)

SmartassV2 is a governor (controls the frequency of the CPU at each give moment) which like the first smartass is generally based on the implementation of interactive with some major changes and the addition of a built in sleep profile (behaves a bit differently when screen is off vs. on).

The smartassV2 improves the very naive scheme which the first smartass had: The first smartass (with the values I set for the hero), would cap the max frequency at 352Mhz for sleep and when screen is on, would do the opposite and keep the frequency at 518Mhz or above. For sleep this was very effective but a bit crude and unclean, and there could be some cases where you would need processing power even when screen is off (something is updating and music is playing and etc.). For screen on, smartass1 was too quick to jump to the max available frequency and again would never go below the 518Mhz, so in a nutshell its was using "too high" frequencies.

SmartassV2, introduce (internally) an "ideal" frequency which is the frequency we are "aiming" for, in some sense. The way I see it is that the "ideal" frequency is a hint to the governor what is a good balance between performance and battery life. Now when screen is on, I set (on the hero) the ideal frequency to 518Mhz which will ensure nice responsiveness but limit unnecessary use of higher frequencies when they are not needed. When screen is off, I set the ideal frequency to 352Mhz (0 will disable the screen state tracking all together). From my testing this will "convince" the governor to spend most of the its time during sleep at the lowest available frequencies. Note, that both during sleep and when awake the entire frequency range (as defined by the "user" - i.e. selected with SetCPU) is used by smartassV2. For example, when the CPU is loaded heavily, the highest available frequency will be used regardless if screen is on or off.

About SavagedZEN I found only this: http://xdaforums.com/showthread.php?t=992017

Cfq

http://en.wikipedia.org/wiki/CFQ

Noop

The NOOP scheduler is the simplest I/O scheduler for the Linux kernel.

This scheduler was developed by Jens Axboe.

The NOOP scheduler inserts all incoming I/O requests into a simple, unordered

FIFO queue and implements request merging.

The scheduler assumes I/O performance optimization will be handled at some

other layer of the I/O hierarchy; e.g., at the block device; by an intelligent

HBA such as a Serial Attached SCSI (SAS) RAID controller or by an externally

attached controller such as a storage subsystem accessed through a

switched Storage Area Network).

NOOP scheduler is best used with solid state devices such as flash memory

or in general with devices that do not depend on mechanical movement to

access data (meaning typical "hard disk" drive technology consisting of seek

time primarily, plus rotational latency). Such non-mechanical devices do not

require re-ordering of multiple I/O requests, a technique that groups together

I/O requests that are physically close together on the disk, thereby reducing

average seek time and the variability of I/O service time.

Deadline

Deadline scheduler is an I/O scheduler for the Linux kernel which was written in 2002 by Jens Axboe.

The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request[1]. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.

Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.

By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.

The kernel docs suggest this is the preferred scheduler for database systems, especially if you have TCQ aware disks, or any system with high disk performance.

Bfq

The Budget Fair Queueing (BFQ) scheduler turns the CFQ Round-Robin

scheduling policy of time slices into a fair queueing scheduling

of sector budgets. More precisely, each task is assigned a budget

measured in number of sectors instead of amount of time, and budgets

are scheduled using a slightly modified version of WF2Q+. The

budget assigned to each task varies over time as a function of its

behaviour. However, one can set the maximum value of the budget

that BFQ can assign to any task.

Next time use Google, please ;)