[kernel] Kernel pour tests

[Invité]

Bonjour,

Je propose un kernel qui intègre :

CPU gouvernor

=============

Hotplug (actif par défaut)

I/O scheduler:

============

BFQ (actif par défaut)

Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it’s budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it’s behavior.

Advantages

---------------

Believed to be very good for usb data transfer rate.

Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)

Considered an accurate i/o scheduler.

Achieves about 30% more throughput than CFQ on most workloads.

Disadvantages

-------------------

Not the best scheduler for benchmarking.

Higher budget assigned to a process can affect interactivity and increased latency.

SIO

Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.

Advantages

---------------

Simple, so reliable.

Minimized starvation of requests.

Disadvantages

-------------------

Slow random-read speeds on flash drives, compared to other schedulers.

Sequential-read speeds on flash drives also not so good.

Et les options:

============

zcache (actif par défaut)

Zcache uses LZO to compress pages passed to it by Cleancache; only pages which compress to less than half their original size are stored. There is also a special test for pages containing only zeros; those compress exceptionally well, requiring no storage space at all.

There are a couple of obvious tradeoffs to using a mechanism like zcache: memory usage and CPU time. With regard to memory, Nitin says:

While compression reduces disk I/O, it also reduces the space available for normal (uncompressed) page cache. This can result in more frequent page cache reclaim and thus higher CPU overhead. Thus, it's important to maintain good hit rate for compressed cache or increased CPU overhead can nullify any other benefits. This requires adaptive (compressed) cache resizing and page replacement policies that can maintain optimal cache size and quickly reclaim unused compressed chunks. With multi-cores becoming common, benefits of reduced disk I/O should easily outweigh the problem of increased CPU usage.

zram

zRam increases performance by avoiding paging on disk and instead uses a compressed block device in RAM in which paging takes place until it is necessary to use the swap space on the hard disk drive. Since using RAM is faster than using disks, zRam allows Linux to make more use of RAM when swapping/paging is required, especially on older computers with less RAM installed.

swap

L'archive suivante http://dl.free.fr/rUlsf1vlj contient:

kernel_12.zip <--- image à flasher depuis le recovery (cwm ou autre)

zram.ko <--- à recopier dans /system/lib/modules et passer les droits à 644 (rw_r__r__)

busybox version 1.20.2 <--- à copier dans /system/xbin, passer les droits à 755 (rwxr_xr_x),

executer : busybox --install -s /system/xbin

Un fichier sysinit.rc à copier dans /system/xbin, passer les droits à 755 (rwxr_xr_x). Il sert à éxecuter automatiquement des scripts lors du boot qui seront placé dans /system/etc/init.d/ par vos soins.

Le noyau est stable mais la swap ainsi que zram qui en dépend réclame un réglage à mettre en place sous peine de faire planter le téléphone (pas de brickage). Le problème de vient d'Android Low Memory Killer.

Pour exploiter zram:

insmod /system/modules/zram.ko (argument optionnel : num_devices=x)

Il est possible de créer plusieurs swap zram, il est conseillé d'en créer une par core mais pour les tests, ce n'est pas vraiment utile.

Un fois le module chargé, il faut définir la taille de la RAM que l'on va utiliser comme swap:

echo "32000000" > /sys/block/zram0/disksize pour utiliser 32Mo de RAM en swap compressé

Si vous avez utilisé l'option num_devices=2:

echo "16000000" > /sys/block/zram0/disksize

echo "16000000" > /sys/block/zram1/disksize

Toujours pour utiliser 32Mo de ram mais en 2 zram de 16Mo (une par CPU core)

ensuite il faut formater la swap:

mkswap /dev/block/zram0

mkswap /dev/block/zram1 (si vous en avez créé 2)

Si vous voulez tester la swap sur une carte SD sans avoir à la partitionner il faut créer un fichier qui servira de swap:

dd if=/dev/zero of=/mnt/sdcard/swap.test bs=1M count=512 (pour un fichier swap de 512Mo)

mkswap /mnt/sdcard/swap.test

C'est à partir d'ici que ça se corse, si on active directement la swap, ça va freezer et ensuite rebooter (voir pas).

C'est lowmemkiller d'android qui pose problème, pas la swap en elle-même.

Si on est connecté par adb shell, il se peut que cela fasse planter le port USB sur lequel est connecté le wiko (un simple reboot corrige le problème ou réinitialisez le port selon votre OS et si c'est possible).

J'ai freezer le mien une bonne dizaine de fois et il n'y a pas eu de problème. Pdroid à eu un freeze et son HP à l'air d'avoir laché (pas de bol) donc évitez la musique pendant le test (j'ai aussi freezé plusieurs fois avec de la musique et je n'ai pas eu ce problème, une faiblesse d'origine je pense).

Maintenant, les choses sérieuse, trouver les bons paramètres à lowmemorykiller pour palier au manque de RAM de nos Slim.

pour connaitre le réglage actuel:

cat /sys/module/lowmemorykiller/parameters/adj

0,1,2,4,9,15

cat /sys/module/lowmemorykiller/parameters/minfree

4674,6136,7598,9646,11694,14031

Ce sont les réglages d'origine du Slim, si vous activer la swap, c'est plantage assuré et il faudra rebooter.

Avec les commandes suivantes, vous désactivez le lowmemorykill d'android:

echo "0" > /sys/module/lowmemorykiller/parameters/adj

echo "0" > /sys/module/lowmemorykiller/parameters/minfree

Ca ne plantera pas tout de suite, la ram va se remplir, la swap aussi, le système va ralentir et va rebooter automatiquement (kernel panic) sauf si vous killez vos applis à la main.

Avec les paramètres suivant, ça mettra plus de temps mais ça plantera au bout d'un moment:

echo "0,1,2,4,6,15" > /sys/module/lowmemorykiller/parameters/adj

echo "1024,2048,4096,819,12288,16384" > /sys/module/lowmemorykiller/parameters/minfree

Une fois les paramètres entrés, il suffit d'activer la swap:

swapon -p 60 /dev/zram0

swapon -p 60 /dev/zram1

swapon -p 100 /mnt/sdcard/fichier.test

-p = priorité

Voila, le plus compliqué est de trouver les bons réglage pour avoir une swap et un Slim stable.

A chaque reboot, il faut recommencer ou vous mettez vos ligne en utilisant init.d (attention de ne pas activer la swap - swapon - temps que les bon réglages n'ont pas été trouvé)

Pour connaitre l'état de la mémoire, taper free ou free -m pour afficher en Ko ou en Mo.

The lowmemorykiller driver lets user-space specify a set of memory thresholds

where processes with a range of oom_adj values will get killed. Specify the

minimum oom_adj values in /sys/module/lowmemorykiller/parameters/adj and the

number of free pages in /sys/module/lowmemorykiller/parameters/minfree. Both

files take a comma separated list of numbers in ascending order.

For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and

"1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill processes

with a oom_adj value of 8 or higher when the free memory drops below 4096 pages

and kill processes with a oom_adj value of 0 or higher when the free memory

drops below 1024 pages.

ActivityManagerService.java tracks the "importance" of processes (is foreground, is running a service, ..) and reflects this importance by setting the "oom_adj" value of the process.

(For info: "oom_adj" is a value of every process under Linux which gives the kernel a hint, which process it can kill in an oom [out of memory] situation. You can see this value on every Linux 2.6 system in the proc directory: /proc/[PID]/oom_adj ). The higher this value is set, the more likely this process gets selected by the kernel's oom killer.)

It seems that on Android the current forefround application gets an oom_adj value of 0 and as soon it's not visible anymore it gets some higher value. I assume the concrete value is dependent by the processes' place in the LRU list.

The out-of-memory killer in the standard Linux kernel only runs in one situation: when the available memory is critical low. However in the Android Linux kernel there is implemented a more fine-grained handling of low memory situations.

This module seems to be more configurable than the kernel's standard out-of-memory killer as you can define more than one memory limit, when it should get active and you can tell it which oom_adj values it may kill.

In other words:

You can say "if free memory goes below XXXX then kill some process with oom_adj greater then YYY; if free memory goes even more below than ZZZ then start to kill some processes with oom_adj greater than XYXY. and so on.."

So it's possible to define multiple memory criterias and matching processes which can be killed in these situations. Android seems to group running processes into 6 different categories (comments taken out of "ActivityManagerServer.java"):

Code:

FOREGROUND_APP:

// This is the process running the current foreground app. We'd really

// rather not kill it! Value set in system/rootdir/init.rc on startup.

VISIBLE_APP:

// This is a process only hosting activities that are visible to the

// user, so we'd prefer they don't disappear. Value set in

// system/rootdir/init.rc on startup.

SECONDARY_SERVER:

// This is a process holding a secondary server -- killing it will not

// have much of an impact as far as the user is concerned. Value set in

// system/rootdir/init.rc on startup.

HIDDEN_APP:

// This is a process only hosting activities that are not visible,

// so it can be killed without any disruption. Value set in

// system/rootdir/init.rc on startup.

CONTENT_PROVIDER:

// This is a process with a content provider that does not have any clients

// attached to it. If it did have any clients, its adjustment would be the

// one for the highest-priority of those processes.

EMPTY_APP:

// This is a process without anything currently running in it. Definitely

// the first to go! Value set in system/rootdir/init.rc on startup.

// This value is initalized in the constructor, careful when refering to

// this static variable externally.

These 6 categories are reflected by 6 memory limits which are configured for the lowmemorykiller in the kernel.

Fortunately, it is possible to configure the lowmemorykiller at runtime!

(But only if you are root). The configuration is set in the file: "/sys/module/lowmemorykiller/parameters/minfree"

So if you want to see the current settings, you can do:

Code:

# cat /sys/module/lowmemorykiller/parameters/minfree

This should produce output like this (or similiar):

Code:

1536,2048,4096,5120,5632,6144

These values are the 6 memory limits on which Anedroid starts to kill processes of one of the 6 categories above. Be careful, the units of these values are pages!! 1 page = 4 kilobyte.

So the example above says that Anddroid starts killing EMPTY_APP processes if available memory goes below 24MB (=6144*4/1024). And it starts to kill unused CONTENT_PROVIDERs if available memory goes below 22MB (=5632*4/1024).

So if you want to try if your Hero goes faster when fewer processes are running you can try to adjust these settings. For example if you practically do not want any empty processes you can set the corresponding value very high. For example, you can set the values like this:

Code:

# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree

This example will tell Android to kill unused Content providers if less then 60MB is available and kill empty processes if available memory goes below 90MB.

Modifié 31 mars 2013 par Old geek

[Wixej]

zram inclus dans le terminal la commande insmod /system/modules/zram.ko programme zram status démarre mais la compression ne se peut encore qu'il faut écrire. Et si cette ligne écrire un script init.d

insmod /system/lib/modules/zram.ko Peut-il doit en être ainsi?

Comment activer zram

[Invité]

Après reflexion, je vais intégrer zram à lowmemorykiller pour qu'il se dém**** tout seul (il aura fallu une nuit de sommeil pour arriver à cette conclusion) :P

Wixej: wait and see ;)

EDIT: Finalement, c'est pas mieux...

Personne pour filer un coup de main ?

Modifié 31 mars 2013 par Old geek

[Wixej]

J'attends la nouvelle version

[Kastoi]

filer un coup de main: non, désolé, j'y connais quedal :D

mais sachant que swapper 2 fonctionne très bien sur des kernel le supportant: peut-être aller voir de ce côté comment ça fonctionne?

[Invité]

Swapper 2, comme tout les logiciels de la sorte, ne sert pas à grand chose, c'est juste pour aider les gens qui ne savent pas utiliser un terminal.

Merci tout de même ;)

[boozaa]

Des nouvelles sur ton travail ?

Encore besoin de testeurs etc

[Invité]

Ben, je cherche toujours...

J'ai essayé tout un tas de solutions différentes, paramètres différents, je suis allé pomper chez samsung une de leur code (zram for android) ainsi que leur code pour la gestion de la swap et gestion de la mémoire mais rien n'y fait, ça plante le système. Pas vraiment moyen de repartir à 0 vu que wiko n'a pas fournis l'intégralité des sources permettant de faire simplement un AOSP, ça va obliger à bricoler sans avoir la garantie du résultat voulu.

J'ai besoin de nouvelles pistes à explorer mais la je sèche un peu.

Je commence à ma dire que ça vient d'android et pas forcément au niveau du kernel mais comme ça plante avant même de fournir la moindre information de débugage, je coince.

Modifié 11 avril 2013 par Old geek

[boozaa]

Ah ouais bien génant.

Espérons que la future source JB du Slim soit plus propre alors.

Je vais suivre de prés les 2 postes sur les kernel customs, celui ci et celui de Pdroid.

Merci et bonne soirée,