[RAZR i General] arman68:
Recommendations:

Preferred:

interactiveX governor with sio scheduler

(better battery life due to cpu speed limited to lowest value, 600 MHz, when the screen is off)

Acceptable:

smartassV2 governor with sio scheduler (same performance when the display is on, but full processing power still available with display off; risk of high battery usage)

Not advisable:

noop scheduler (no performance gain, but causes major stuttering and lag in user interface and apps)

2013-04-14 update: see post #5 for a battery saving test of those 2 governors, with the display on. The conclusion remains the same, but it also shows the better cpu frequency ramping logic of interactiveX.

Long version:

Thanks to Omar-Avelar kernel, I was able to perform some tests, to find out which governor and scheduler are best for the xt890. I restricted myself to smartassV2 and interactiveX, which are generally considered best governors. Both are based on the interactive governor, which is the default in motorola JB retail kernel (ICS used the less than optimal ondemand governor instead).

smartassV2 scales rapidly to an intermediate frequency, and more slowly to the max frequency. Different optimal frequencies are used for screen on and off, and it scales down rapidly. There is no limit for highest frequency when the screen is off. It aims to provide a good balance between performance and battery.

interactiveX fine tunes the interactive logic to minimize unnecessary cpu spikes, and adds a suspend/wake logic which limits the cpu frequency when the screen is off. It aims to maintain the performance of the interactive governnor, with more stability and better battery life.

For the schedulers, I tested the noop (motorola default in JB and ICS) and sio schedulers.

noop is simple and fast. Its I/O pattern is very suitable for flash drive (performs very badly on normal hard drives though, due to the random nature of its I/O). Battery friendly due to low overhead and few CPU cycles. However, there is no starvation detection, and long requests can lock down the CPU.

sio is similar to noop with starvation detection, which guarantees smoothness. Good ratio of writes to read ensure that all transactions are equal. The downside is that in theory read speeds are not as good as with other schedulers.

Test method:

I think most synthetic tests are a poor benchmark, as they will often highlight a particular flaw or strength, which has little impact in real life usage. Therefore, I did the following:

launching Real Racing 3 game (average of 2)

Epic Citadel benchmark

large file copy (1.38 GB) from external SD to internal storage while playing music (average of 2)

large file copy (1.38 GB) while playing HD movie with HW+ decoding with MX Player (average of 2)

large file copy (1.38 GB) while playing HD movie with SW decoding with MX Player (average of 2)

gameplay Real Racing 3

large file copy (1.38 GB) cancelled after 10%

Test results:

1 2 3 4 5
interactiveX + noop 52s 56.9fps 98s(a) 124s 84s(b)
interactiveX + sio 52s 55.5fps 97s 129s 96s
smartassV2 + noop 51s 56.3fps 103s(c) 103s 89s
smartassV2 + sio 52s 56.0fps 125s 101s 97s

(a) music stopped 3 times, for approximately 1s each.
(b) movie stopped for 3s.
(c) music stopped 1 time, for 10s.

6: All combinations behaved similarly during Real Racing 3 gameplay: frame rate too low, with (very) occasional stuttering. Epic Citadel gameplay was smooth in all cases.

7: with noop scheduler, cancelling file copy always hangs for a very long time; whereas with sio it is instant. In addition, the android UI and responses to events (eg: adjusting volumes) is very laggy on noop during large file operations.

Conclusion:

For schedulers, the choice is clear: sio is much superior to noop. The noop scheduler does not seem to offer any io speed gain over sio, but adversely affects performance.

For governors, no difference was observed between smartassV2 and interactiveX. However, when the display is off, interactiveX caps the maximum frequency to the low value (600 MHz), while smartassV2 quickly ramps up the frequency; this should result in significant battery savings with interactiveX, especially when affected by bugs like deep sleep prevention due to rx_wake wakelocks.