[Kernel][JB][3.0.51][Aroma]Yank555.lu kernel v2.4b

[BlackJack89]

Nuovo Kernel per i nostri Jelly Bean, basato sull'update 6 delle sorgenti Samsung...

Yank555.lu kernel v3

Compatibile con:

• Sotmax JB Ultimate Stock v2, v6, v7, v8, v9,v10
• ARHD 11.0.0, 12.0,13.0 ****
• Stock Deodexed DLIB, DLJ1, DLJ2, DLJ4
• Stock Odexed DLJ1
• InsertCoin 2.1.0, 3.0.0
• WanamLite JB 4.0.1
• Dragon Rom v4
• Omega v30, v31, v33, v34, v35
• NxTGen ROM XXDLJ4
• VikingRom 10
• VikingWay 1.1
• Ultima Rom 4.1.1
• Turkbey LJ1
• crDroid V7.2
• MIUI - RAYGLOBE V. 7

Non funziona con ICS o CM9/10 o AOKP andate QUI

Piccola nota per i possessore della ARHD:

since this kernel uses ARHD's ramdisk, init.d support on ARHD will not be broken, so in Aroma please chose "no" for the init.d question as the kernel/ramdisk does not need to take care of it. As for other ROMs, well if init.d support is implemented on their respective ramdisks (not through init.post_boot.sh script), then you might check if by choosing no you loose init.d support. If so, reflash the kernel and choose yes.

Cosa Aspettarsi da Questo Kernel:

• be as stable as possible to be usable as a perfect daily kernel (conservative approach)
• give a good battery life while being snappy
• give users an easy and safe way to customize settings
• be and stay as close to stock Samsung as possible
• allow only for moderate CPU OC (up to 1.6GHz)
• include some standard Linux features missing in stock kernel (e.g. swap support)
• include interesting commits by other devs (giving proper credit, of course !)
• updated to kernel.org Linux

Cosa non aspettarsi:

• Modificazioni Sperimentali
• il miglior kernel del mondo
• Non fa il caffè

Versione Disponibile:

Changelog v3.1b

• Complete rebase on Samsung JB Update 7 sources (Linux 3.0.31)
• updated to kernel.org Linux 3.0.59
• using XXELLA ramdisk
• swap support
• zram support (Android optimized)
• /proc/config.gz support
• optimized for size
• ntfs (rw) support (kernel support only)
• Forced Fast Charge v1.2a
• CPU OC up to 1.6GHz
• Triangle away support
• dynamic fsync support (faux123)
• TCP westwood congest ctrl (faux123)
• Proport. Rate Reduction TCP (faux123)
• ARM AES/SHA1 (faux123)
• JIT compiler for packet filters(faux123)
• fix ipv6 protocol lookup (faux123)
• ipv4 check ret.val. dst_alloc (faux123)
• ipv6 check ret.val. dst_alloc (faux123)
• updated LZO compression (faux123)
• do_fsync() to fget_light() (faux123)
• disabled mali state tracking (AndreiLux)
• reduce mali utilization sampling timeout (AndreiLux)
• added SIO scheduler
• added ROW v4 scheduler
• black crush fix (AndreiLux/AndiP71)
• added lulzactiveq CPU governor
• sysfs interface to delay fsearlysuspend (Yank555.lu, base idea Codeworkx)
• Boeffla-Sound: Engine 1.4.3 (AndiP71) - Huge thanks for offering me to include his hard work and great sound engine

Download

...Changelog Versioni Precedenti al Quarto Post...

Guida nel 5° Post


Non sono io l'autore del Kernel, la discussione Ufficiale QUI
Vogliate inoltre scusarmi per l'enorme mole di Info su Aroma, so che è stressante leggere tutto, nei giorni prossimi cercherò di Tradurre e Riassumere le Spiegazioni date dell'Autore del Kernel

[BlackJack89]

Installazione del Kernel e cenni Documentazione Ufficiale del Tweaking su AROMA

Requisiti

• Rom JB
• Root e CWM
• Nandroid Backup prima di Partire con il Flash

1. Mette il pacchetto nella SD
2. Entrare in Recovery
3. Wipe Cache e Dalvik
4. O script per la pulizia del Kernel
5. Flashare il pacchetto....
6. Ore tocca ad Aroma.........

Questo Kernel è molto personalizzabile...Vediamo le Varie Opzioni

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 and cfq" 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.

• Virtual memory

Perfect transition to swap
As I just said, memory is divided into memory blocks of 4096 bytes. Each memory block holds also the information when it has been used for the last time.
Considering this, one single app will be using many blocks. Some of those the app will be using a lot, some it won't. Take a simple card game. When you're playing, you're not using the app's settings menu, thus not using any of the blocks that hold those parts of the app.
Swap is a process that is used in most of modern operating systems. The virtual memory management system (that's swap !) will swap out all the blocks that were not used for a certain time, this "certain time" is influenced by swappiness and a few other parameters that we can change.
The plus is that the memory blocks that have been swapped out will free up RAM to be used by other apps, thus allowing for more apps to run at the same time.
On the other hand, if you need a swapped out block, that will cost extra time, since it's not located in memory any more but on the swap partition, so it will need to be reloaded into RAM (possibly by swapping out another block to make room for this).
That should give you a glimpse on the benefits and the costs of using swap. There's that damn balance once again...
That should also give you an idea of why LMK settings matter, since if almost no free ram is available, a swap in will generally cost a swap out first then the swap in !
Consider swap as a way to have only part of the apps in RAM instead of having all of it, and as such allowing for more apps to run at the same time.
BTW, it does not add RAM, you can only add RAM by actually adding physical RAM, anyone telling you otherwise is either lying or does not know what she/he's talking about

• Hardswap

My favorite, since it adds virtual memory, without taking anything for it, swapped out memory pages are stored on a separate partition on the external SD card. The drawback is it's actually slower than using internal memory, but I don't like that, wearing internal memory is kind of bricking the phone, where wearing out an SD card just means replacing it, much cheaper. And it's much slower than zram, but ... read ahead ...

• zram

The one I don't like that much. It's fast, yes. It will take less RAM than it will give swap in return, still true as it uses compression to store the swapped out memory pages, so you'll be fitting more pages in swap than swap actually uses pages to store them.
But, there's always a but, you now understand that swap is not RAM, so taking RAM away to use as swap, is removing RAM from running apps. The more zram, the more RAM you take from your apps to acutally run.
But again, since it's the fastest, maybe it's going to fit your need better than hardswap, so you need to try, and with Aroma, that's real easy to do
As a sidenote, it might be interesting to read the FAQ in my hardswap thread if you want to know some more about this.

[BlackJack89]

• 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

• Dynamic fsync settings

This is a goodie by faux123, so all credits go to him for creating this unique feature !

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

The hardest to explain

Let me try it this way. Most mods will change settings, and to do this so that those settings stick, they need to do it everytime your device boots.

To do so, 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.

[BlackJack89]

Changelog Precedenti Versioni

Changelog v2.4a
added dynamic cpu_max adjustment so CPU apps trying to set freq. above max. freq. will not be able to

Changelog v2.4
added asynchronous PPP support in kernel
removed PPPoE support in kernel
limited cpu freq. table to disbale freq. above CPU max to avoid using higher freq. at any time (even few seconds) - This will impede setting freq any higher than chosen in Aroma, even with SetCPU/System Tuner ..., except by changing the value in /sys/power/cpufreq_max_limit !
/sys/power/cpufreq_max_limit now set by Aroma script to limit CPU frequency from using more than what user wants (usage up to 1.4 during boot is normal even if lower CPU max. chosen in Aroma)

Changelog v2.3
updated to kernel.org Linux 3.0.51

Changelog v2.2a
Forced Fast Charge v1.2a : (sorry forgot something )
custom fast charge for usb now possible up to 1000mA/h (as per request by bcky84)

Changelog v2.2
added dynamic file sync by faux123 setting in Aroma
Forced Fast Charge v1.2 :
custom fast charge for ac now possible up to 1500mA/h
added failsafe for custom current that can be disabled so that ANY value up to 2100mA/h is accepted as custom AC / USB current. This is only available manually through the sysfs interface (set /sys/kernel/fast_charge/failsafe to 0 to unlock) and not in Aroma, use at your very own risk and only if you really know what you're doing ! (as per request by bcky84)
added PPPoE support in kernel

Changelog v2.1
updated to kernel.org Linux 3.0.50 (except this commit which conflicts with Samsung JB Update 6 sources)

Changelog v2.0
rebased on Samsung JB update 6 sources (Linux 3.0.31)
updated to kernel.org Linux 3.0.49
merged with Yank555.lu v1.7 adding all goodies up to what we have in v1.7 !

Changelog v1.7b
added swappiness setting in Aroma for virtual memory so you can choose it, for hardswap and for zram as well (hardswap used to set swappiness to 100)
the kernel is unchanged still v1.7

Changelog v1.7a
added /system/etc/init.d folder creation if it does not exist (only when selecting init.d support = yes)
the kernel is unchanged still v1.7

Changelog v1.7
updated to kernel.org Linux 3.0.48

But use with great care, the changes to get past 3.0.39 were quite tricky, so keep your eyes wide open and report anything strange. Thanx !

Changelog v1.6a
added option in Aroma for init.d support by kernel/ramdisk
But use with great care, executing the scripts twice (once by kernel/ramdisk and once by ROM) may be a problem ! So know what you're doing, you have been warned
the kernel is unchanged and will still display v1.6, if you have v1.6 already you only need to flash this if you need to add init.d support
I reuploaded v1.6a with LMK defaulting to "not set here" as using Medium without swap induces slight lag (if you use swap, you can manually select Medium to get back to the previous default)

Changelog v1.6
mdnie: custom settings - Includes hardcore sharpnes fixes, and black gamma curve adjustment for black crush (AndreiLux)
used more "conventional" default Aroma settings

Changelog v1.5a
removed busybox binaries, hoping to find all I need in recovery (incompatibilies with TWRP Recovery)
the kernel is unchanged and will still display v1.5, if you have v1.5 already no need to flash this

Changelog v1.5
added Aroma installer with script generator, allowing to customize the following kernel settings when flashing :

CPU maximum frequency (underclocking down to 1.0GHz and overclocking up to 1.6GHz)
Consider I/O as CPU load
MMC I/O (scheduler & readahead buffer size)
Android Low Memory Killer
Virtual memory (hardswap / zram)
Fast charge

Changelog v1.4b
reenabled Contiguous Memory Allocation (introduced by Samsung on JB)
disabled mali state tracking (AndreiLux)
reduce mali utilization sampling timeout (AndreiLux)

Changelog v1.4a
disabled Contiguous Memory Allocation (introduced by Samsung on JB)

NB: Just a test on my end to compare with and without, will be added
again in future releases.
Available user RAM drops back to ICS (779Mb) instead of JB (833Mb)

Changelog v1.4
update ramdisk to ARHD 12.0 (mike1986)

Changelog v1.3b
default CPU frq 1.4GHz (max. 1.6MHz) (Yank555.lu)
removed zram activation from init.rc (Yank555.lu)

Changelog v1.3a
zram support (Android optimized)

Changelog v1.3
TCP westwood congest ctrl (faux123)
Proport. Rate Reduction TCP (faux123)
ARM AES/SHA1 (faux123)
JIT compiler for packet filters(faux123)
fix ipv6 protocol lookup (faux123)
ipv4 check ret.val. dst_alloc (faux123)
ipv6 check ret.val. dst_alloc (faux123)
updated LZO compression (faux123)
do_fsync() to fget_light() (faux123)
ntfs (rw) support (kernel support only)

Changelog v1.2
new dynamic sync control (faux123)

Changelog v1.1
OC up to 1.6GHz (Yank555.lu)
USB forced fast charge (Yank555.lu)

Changelog v1.0.38
updated to kernel.org Linux 3.0.38

Changelog v1.0.35
updated to kernel.org Linux 3.0.35

Changelog v1.0
Samsung JB update 5 sources (Linux 3.0.31)
using ARHD 11.0.0 ramdisk (mike1986)
swap support
/proc/config.gz support
optimized for size

[BlackJack89]

Per Cambiare Kernel, dovete Flashare Questo Zip prima

Kernel Clean

[BlackJack89]

Guida Breve ed Efficace AROMA

- Cpu Frequency Settings
Imposta la frequenza massima del processore
- I/O Cpu load
Lasciate com'è, imposta il carico della cpu
- MMC buffer potete raddopiarla, ma io l'ho lasciata a 2048
- MMC scheduler
cfq
- Memory Killer
A vostro piacimento ragazzi
- HardSwap
Se sapete che fare ok, altrimenti lasciate tutto com'è
- Fast Charge
Default
AC 1000mA o 1100mA

Ora se collegate il vostro device al PC con una porta USB 3.0 selezionate il voltaggio corretto, se usate USB 2.0 lasciate tutto com'è.

Per lo Script. Ini se sapere cosa comporta, abilitatelo, per chi usa ARHD non attivatelo


FINE :-D


Stampato al Laser

[BlackJack89]

anche se nessuno lo usa, ho aggiornato anche questo Topic, ha aggiunto il supporto al Pad della XBOX 360...

[Enr1988]

anche se nessuno lo usa, ho aggiornato anche questo Topic, ha aggiunto il supporto al Pad della XBOX 360...

Ottimo kernel, fluidità perfetta...unica pecca secondo me il battery drain a schermo spento. .

Inviato dal mio GT-I9300 con Tapatalk 2

[BlackJack89]

Ottimo kernel, fluidità perfetta...unica pecca secondo me il battery drain a schermo spento. .

Inviato dal mio GT-I9300 con Tapatalk 2

Fate Presidente quest'uomo, era ora che qualcuno usasse questo Kernel!
Dicci la tua configurazione!

[Enr1988]

Fate Presidente quest'uomo, era ora che qualcuno usasse questo Kernel!
Dicci la tua configurazione!

Frequenza cpu stock 1.4ghz, Scheduler I/O Noop o Row, Custom Fast charge 600/1100 , Low Memory Killer Aggressive, MMc reader 1024 kb, dynamic fsync Enabled