[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] CTCaer:
Seems interesting. One thing is sure though. That it will not behave the same. Nexus 7 has quite fast nands (lowest i saw was 130mb/s)

The problem in our phones is that it struggles when lots of data have to be read or written. It takes an impact on cpu.

So for now untill I test it you can use SIO which has almost the same thoughtput as deadline (in some situations even better)

and it uses a lot less cpu. About cpu, bfq is currently the best, it has great thoughtput but not as good as sio and deadline.

(Also noop has the less impact on cpu. Don't use it though, the thoughput (mb/s) is ****ty. It will improve UI respnosiveness when

loading data or writing but it will reduce the speeds by a looot and the end result will be the same. Better some lag for a little time, than little lag for a long time.)

Here are the commands to add to your init.d scripts, so you can make the internal nand and sd card use SIO as i/o scheduler:

# sio for sd
echo "sio" > /sys/block/mmcblk0/queue/scheduler

# sio for nand
# no need to echo sio to mtdblock1, 2 and 3
# Echoing "sio" to one of the partitions it will change it for all nand partitions.
echo "sio" > /sys/block/mtdblock0/queue/scheduler

I will test ROW scheduler. In the next versions if the results are the same with sio or if the use of cpu is as high as deadline, I'll make SIO default io scheduler.

The good thing is that ROW has some scheduling priorities like BFQ.

And well if you read http://lwn.net/Articles/509829/ seems pretty neat.

Well to all comments about debloated stock roms:

Ofcourse they are fast. A debloated stock rom is as fast and good as a custom stock based rom.

They are the base for these projects. Why should they behave differently?

The zRam must always be almost full after some phone usage. If not something is wrong.

Also about the lag on opening closing apps after a long usage without restart is normal.

That doesn't mean we shouldn't improve it. Even if I have done changes to android LMK the buggy caching is still there.

There are 3 thing that can be done:

1: you can just restart your phone after 3 days.

2: run lmk configs that suit your usage through supercharger or another script/app

3: run a script like supercharger's flush cache. It will make your phone behave almost as it was restarted.

This problem is bound to be on our phones with ics. This kernel helps also a little with it's 11mb more total ram.

But we still only have 350mb ram.

Anyway long story short: That shows up because android caches apps so they can open faster next time and this uses ram which is freed ofcourse when needed. But when the freeing up is done it introduces a hundredth ms delay.

Also if you use stock zRam settings you can try and reduce them. Default is 60mb of data that can be compressed.

That means that it will use max aprox. 25mb of ram. If the data can be compressed more it can only use as far as 14mb.

Reduce it to 30mb or less. In a post in this thread I explained how zRam works. Check it and have in mind that the value that you give is

how much data can compress, NOT how much ram it uses.

you need to write

cat

/sys/module/lowmemorykiller/parameters/adj to show the results. Not only the filepath.

You need that cat command. If still asks from permissions write su 1st to take root access

Also as you would see the values are default, because everyone uses his phone differently and also the half management goes to services.jar.

In my case I use a supercharded services.jar and a supercharger script with multi-tasking values.

Others prefer values that make the phone free up more ram for snappy opening of apps and for games.

But for me I want what I use to remain there and freed up only when needed (normal free ram for me after a good usage of apps is 28mb).

(For games it's the same imo and maybe worse when you have the killing values high. Because there's more constant killing. But if the game has constant ram usage the killing disappears because the services never restart.

In the other hand that can also show up with low values.)

There are many results on how the phone behaves with different lmk values. It always has to do with the user's usage though.

Each to their own.

ps: And never forget that the problems won't disappear magically.

ps2: Here's something funny: A friend of mine has NEO V and he broke his camera.

I made him a custom kernel with ram changes like in CTCaer kernel and also made camera pmem 0.

Now his phone has almost 400mb total ram (47mb more than ours) and it's a lot faster than my Ray.

As you can see a little increase of total ram made his phone snappy as sick.

ps3: You have a broken camera? Write here and request a custom CTCaer kernel with no camera functionalities. :P