[Kernel][AOSP/CM 4.1.x/4.2.x][3.0.57][Aroma] Yank555.lu v1.3f

[BlackJack89]

Visto l'assenza di Kernel per le Rom basate su AOKP e Company, mi permetto di postare uno dei Kernel più utilizzati su XDA

ATTENZIONE: NON PER SAMMY ROM SOLO AOKP E CYANO!!!!!


NOVITA' FIX DELLE SD!!!


Caratteristiche

• Basato sulle Sorgenti della CM 10
• Approccio conservativo, per essere il più stabile possibile
• Facile da personalizzare
• OC possibile fino a 1.6GHz
• Supporto Swap e altre caratteristiche Linux

Settaggi Stock

Yank555.lu :

• CPU : 1.6GHz, LulzactiveQ
• I/O : 512Kb readahead buffer, row scheduler
• LMK : Medium
• Swap : hardswap, no zram, swappiness 70
• Fastcharge : enabled, 1000mA USB & AC
• Soundlevel : speaker +3, stock for headphones
• Dynamic fsync : enabled
• CIFS kernel modules : enabled
• Flash : ask
• init.d support : no

Compatibilità testata con:

• Paranoid Android 2.54 by gokussjx
• Helly_Bean (CM10)
• CM10
• Slimbeam ROMs
• Temasek's nightly V99
• AOKP
• Jelly BAM
• Rootbox
• Baked blackbean 6
• PACman ROM
• SuperNexus 2.0
• CM10.1 Nightly

Installazione:
Wipe dalvik e cache
Flash zip
Settaggi AROMA POST 2 e 3
Ricordo che i post riguardanti aroma sono lunghi ed esaustivi, ma all'atto pratico sono Semplici!
Provare per credere
Al limite basta chiedere

Changelog v1.4c
updated to kernel.org Linux 3.0.60
updated to Boeffla-Sound: Engine 1.4.4 (AndiP71)
fix issue with mic mode functionality interfering with call functionality sometimes (where partner could not hear anything during a call)
updated CM kernel sources : update mdm & update sensors and firmware (cmenard)
Sudden Death Syndrom Fix


Link e supporto XDA

Per ROM basate su 4.1.x QUI
Per ROM basate su 4.2.x QUI

[BlackJack89]

CPU frequency settings

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

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

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

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

[BlackJack89]

Dynamic fsync settings

Many kernels just disable synchronous writes to file to speed up system. While this works neatly, it is also dangerous as processes believe that file writes are actually sync'ed to disk (or mmc media in our case) while this is not yet true !

The gain is a noticably smoother user experience, but the risk of doing so is to have a corrupted filesystem if the device crashes, user pulls battery, battery fully depleats ... so that the device is turned off unexpectedly.

To allow for the benefit, but to minimize the risk, faux123 created dynamic fsync, which while the screen is on, will defer file sync temporarily, but when screen gets turned off, a flush is called to synchronize all outstanding writes keeping your data safe.

Now it's up to you to either use this unique feature (that has been enabled by default up until v2.2) or choose to stay stock by disabling it, thus writes being done synchronously, which is safer but also slower.

init.d script support

There is a folder called init.d, it's actually located in "/system/etc/init.d" and it will hold scripts which will be executed everytime your device boots.

Well and this "will be executed" is the thing we need to focus on here. This can be either handled by the kernel (or rather ramdisk to be more precise, which comes with the kernel), or it can be handled by the ROM (like this is the case in mike's ARHD ROMs).

So depending on the ROM you have, you either need the ramdisk to handle this, or the opposite just don't want it to take care of that, since if both do, the scripts will be executed twice, which may be fine, but may also be a problem...

So you need to know what your ROM does here, and according to what the ROM does, have or not have the ramdisk do it.

So to make this as easy as possible, ask in your ROM thread if the ROM handles init.d.

If the ROM does, then choose no in Aroma.

If the ROM does not, then choose yes in Aroma.

[dieguccio]

non dimenticare il link al thread ufficiale, lo hai scritto ma non inserito
stai invecchiando

[BlackJack89]

non dimenticare il link al thread ufficiale, lo hai scritto ma non inserito
stai invecchiando

Hai ragione, domani lo metto...
Tanto nessuno lo usa questo bel kernel

Inviato da un Impulso di 90°

[BlackJack89]

Aggiornamento per le ultime AOPK

[BlackJack89]

FIX delle SD!!!!

Aggiornato post n°1!!!

[alexander93]

Io per staccarmi un po' dal siyah l'ho messo in test ora vediamo come se la cava con cyanogen 10.1

[BlackJack89]

Io per staccarmi un po' dal siyah l'ho messo in test ora vediamo come se la cava con cyanogen 10.1

Oh la! Era ora che qualcuno si staccasse dal siyah

[alexander93]

Oh la! Era ora che qualcuno si staccasse dal siyah

Si visto che per rom aosp ci sono ben pochi kernel ho deciso di provarlo. Flashato oggi e sembra che si stia comportando bene