CPU frequency settings
Quote:
CPU maximum frequency
I'd say this one's pretty selfexplaining, it will let you chose at what maximum frequency you want to limit your CPUs. Stock is 1.4GHz, so allowing (up to 1.6GHz) more means you're overclocking the CPUs (expect better perfomance, but to the cost of a slightly higher battery drain !), restricting this to anything lower than 1.4GHz means you're underclocking the CPUs (you can expect to save some battery juice, but to the cost of lesser performance.)
Since our S3 has quite a powerfull CPU, if you use your S3 for basic tasks only (browing, texting, calling, reading emails...) you may use lower freqs. and not feel any real loss in speed, but if you're gaming etc. expect to feel the difference.
Consider I/O as CPU load
This one's probably not as selfexplaining. This will set the governor's "io is busy" property to either 1 (= yes) or 0 (= no). If set to yes, this means that if the CPU is waiting for io's to complete, it the governor will consider this as load, and continue to throttle up the CPU freq. If on the other hand it is set to no, in this case, the governor considers this as not being a load, and CPU freq. will start throttling down.
I like to keep this to yes, as I'm a convinced "race to idle" theory fan, which means best battery drain is achieved if we do what we have to do as fast as possible (higher CPU clock) so we can put cores to sleep sooner and save juice. There are also others that say better battery is achieved by keeping the CPUs on low freqs. but taking longer.
Don't expect the difference to be huge, and whatever your oppinion on this, I'd rather provided you with the choice, so it's up to you what you consider being the "truth"
MMC I/O Settings
Quote:
These settings will be applied only 2 minutes after boot is completed, as we need to wait that the external sd card has become ready in the system before applying this.
MMC readahead buffer
This will set how much more of a file the system will read than an app actually asks for, so that when the app asks for the next data, it is already available, thus winning the time to go get it on internal / external memory.
Sounds nice, first reflex, put it to the max. As you can see, I've limited the choices to 4Kb max, that is not a technical limit, but more of a failsafe against this very same reflex.
While reading files sequentially, e.g. from the beginning to the end like on MP3s or movies, more is better since we are going to read what's next in the file anyway, we want to listen to the rest of that song, watch the rest of that movie, if on the other hand the app reads randomly within a file, like a database would do, e.g. your satnav reading the map for you, it will jump reading from here to there, what is the point of reading too much ahead in this case ? Well none, you'll have your system read loads of data that the app is never going to ask for, so it's counterproductive.
As so often in life, you need to find the perfect balance, but this balance may be different depending on what you do more...
MMC I/O Scheduler
I'll keep this one short, have a look here, considering that we only have "noop, dealine, cfq, sio and row" in this kernel. I couldn't tell you more about this anyway
Low Memory Killer Presets
Quote:
All the apps you run are put into different categories (as a degree of importance or a kind of service they provide).
Memory is divided into memory blocks that apps can use. In Android one memory block has 4096 bytes. Each category will have a number of memory pages limit, which as soon as free memory drops below of that limit, will make LMK start killing tasks of that category.
So the higher the limits, the sooner it will start its blood bath and kill away, or put otherwise, the higher the limit, the more free memory you will have at any given time.
ALMK is your guardian of free memory if you will.
Again, balance is key, too high, and you'll end up not having any multitasking at all, but loads of free memory that's not used, bad idea, too low, you might run out of memory, which induces lag and might even trigger Linux's OOM (out of memory killer), which will shot a sight without looking what it's shooting at (more or less), so you don't want to wake that monster either.
Plus depending on the use of swap and what kind of swap, these settings will also have an indirect impact.
Fast charge
Quote:
My favorite first kernel mod, the one that gave me the courage to go the whole way to compiling a kernel as I just needed to port it on my Sensation at the time.
This is the S3 flavour of the mod, it has a few options :
Substitute
This is the classic fast charge mod, which just tells the device to charge on a USB port as if it were an AC charger. It's a but simplistic, but back in the days (that's just a few months back actually) it was fine.
I've kept the logic, since there are apps on Play Store that allow to enable / disable this mode from an app/widget.
But I consider this deprecated.
Custom current
Now the S3's hardware allows for something quite nicer, we can actually set the charging rate as we wish ! In this mode, well you just chose at what rate you would like to charge your battery when connected to a USB port (475mA/h is default) or an AC wall charger (1000mA/h is default).
Be aware that you may fry your USB port if you draw too much and it overheats, but if it's a port that fully complies to the standard, it should shut down (stop giving current) if you draw too much from it.
Also, charging at higher rate than 1000mA/h (= wall charger rate) you may shorten the life of your battery, so it's up to you to use this, again, with balance