Tutoriel Tuto Kernel - Configurer/Tweaker son Kernel [Description gouverneurs + I/O Scheduler + init.d]

  • Auteur de la discussion totochigna
  • Date de début
T

totochigna

Membre VIP
Inscrit
19 Novembre 2012
Messages
342
Points
16
  • #1
1403365474-kernel.png

Vous pouvez aussi consulter l'excellent tuto sur les gouverneurs réalisé par Joe! Il est accessible . :smile:

Hello ! :smile:
Aujourd'hui, petit tuto sur comment configurer son kernel, pour le personnaliser a fond !
À noter que ce tutoriel peut être utilisé sur tous les kernels (à l'aide d'un init.d) ou, par exemple, sur Siyah ou Googy Max, les deux possédant une application permettant de personnaliser le kernel plus facilement !

--- LEXIQUE ---

Étant donné que je vais utiliser des termes qui peuvent vous être inconnus, je vais vous faire un petit lexique des termes utilisés soit ici, soit dans le init.d, ou dans l'application STweaks, etc.

HDD = Disque dur

SSD = Stockage flash

CPU = Processeur (Ce qui fait des millions et des millions de calculs sur votre appareil)

Gouverneur CPU ( ou "Governor" en anglais ) = Ce qui définit comment le CPU fonctionne. Si vous ne comprenez pas, je vais faire simple: C'est le "truc" qui dit quand le CPU doit monter en puissance, et quand il doit baisser.

Ordonnanceur Mémoire ( ou "I/O Scheduler" en anglais ) = Ce qui controle les accès mémoire, quel processus va être exécuté avant l'autre. C'est lui qui va trier les "demandes", qui l'a faite avant qui, etc.

GPU = Carte Graphique (Ce qui fait que vous puissiez voir Android sur votre écran)

UV = "UnderVolting" Le fait d'alimenter un peu moins que d'habitude le CPU, ou encore le GPU. Ceci, bien qu'il réduit la tension de fonctionnement d'un composant, ne réduit pas les performances. Faire un UnderVolt gagne en consommation, puisque moins d'énergie est utilisée, et réduit la chauffe du composant. Veillez, cependant, à ne pas trop abuser de ceci, au risque de voir votre appareil incapable de démarrer...

Tweaks = Modifications

OC / UC = "Overclocking" / "Undervolting" Opération qui consiste à monter ( over- ) ou a baisser ( under- ) la fréquence (puissance) d'un composant. L'OC augmente les performances, au détriment de la batterie. À l'inverse, l'UC baisse la vitesse maximale du composant, ce qui économisera de la batterie !


--- GOUVERNEUR CPU ---

Nous allons voir les différents et principaux gouverneurs CPU pouvant être utilisés sur Android. Veillez, par contre, à avoir un kernel compatible !

Ondemand: Gouverneur par défaut. Le but du Ondemand est d'être fluide, sans pour autant abuser inutilement du processeur. Dès qu'une activité est détectée, le gouverneur passe le processeur à la fréquence maximale. Il utilise comme critère le temps d'utilisation du processeur. Une activité est détectée? Hop! Le CPU passe à la fréquence maximale et diminue en fonction de l'utilisation. Pour vous, cela peut paraître superbe comme gouverneur, mais cela ne l'est pas trop pur la batterie (et parfois même en terme de performance). Puisqu'il se base surtout sur le temps d'utilisation et la charge, il peut se retrouver à alterner maximal, minimal, maximal, minimal, ce qui bien évidemment, consomme beaucoup de batterie !
OndemandX: Si jamais, les gouverneurs "X" sont une version améliorée. Ce gouverneur, contrairement au Ondemand classique, possède un profil utilisé quand l'écran est éteint. Dans ce cas, la vitesse maximale du processeur est de 500MHz (0,5GHz). Contrairement aux autres gouverneurs, Ondemand et sa version améliorée sont relativement dépendant de l'ordonnanceur mémoire choisi. Le meilleur pour ces gouverneurs étant le SIO (Ne vous inquiétez pas, on verra plus tard les différents Ordonnanceurs mémoire).

Conservative: Similaire au Ondemand, mais lorsqu'une tâche est détectée, il n'augmente pas le CPU à la fréquence maximale. Il l'augmente progressivement selon la charge. Lorsque l'écran est en veille, le processeur reste fixé à la fréquence minimale.

Interactive: Contrairement aux précédents, celui-ci est une version plus rapide du Ondemand. Le but de ce gouverneur est d'être plus rapide, donc un peu moins de consommation. Il a été conçu pour s'adapter à la charge du CPU. Au lieu d'augmenter la fréquence à intervalles réguliers, l'Interactive détermine la façon d'augmenter le CPU en sortant de veille. Le grand avantage majeur pour ce gouverneur est:
- Une hausse plus cohérente de la fréquence, car Interactive se base sur une évaluation de la queue des tâches en attente (comme les autres gouverneurs), mais en plus il se base aussi sur une notion de temps.
Ce gouverneur est Ondemand, mais en plus intelligent. Au lieu de vérifier la charge toutes les XXX millisecondes, ce qui peut causer un ralentissement entre deux vérifications, Interactive va tout de suite analyser si le CPU doit être augmenté en sortie de veille. En sortie de veille, le CPU définit une sorte de minuteur. Si le CPU est chargé entre le début et la fin du minuteur, il est aussitôt réhaussé. S'il est vraiment très chargé durant le minuteur, alors là, Interactive le fixe à la vitesse maximale.

InteractiveX: Même chose que le OndemandX par rapport au Ondemand. Ce gouverneur ajoute le même profil de veille.

Luzlactive: Gouverneur assez récent, basé sur l'Interactive et le Smartass (expliqué ci-dessous), c'est un gouverneur assez connu et favori de la plupart des gens. Il existe 2 versions:
- V1: Quand la charge de travail est de >=60% sur la fréquence actuelle, le CPU passe à la fréquence supérieure. Quand elle est de <60%, il passe en dessous. Ce gouverneur introduit également un profil de veille. Quand l'écran est éteint, il passe à la fréquence minimale, et n'augmentera jamais.
- V2: Même chose que la première version, mais il est personnalisable avec 3 paramètres: Le pourcentage (60% sur le V1), et de combien de paliers il doit monter, ou descendre (de 1 palier sur le V1)


Smartass: Ce gouverneur est en fait le Luzlactive, mais totalement réécrit. Son but est de maximiser la batterie sans perdre en fluidité et en performances. Il existe également 2 versions:
- V1: Cette version possède le désaventage de grimper en fréquence beaucoup trop souvent. Et la fréquence minimale lorsque l'appareil est actif n'est pas à 200MHz, ce qui va consommer plus de batterie.
- V2: Ce gouverneur, lorsque l'écran de l'appareil est éteint, ne limite pas le CPU à une fréquence maximale, pour lui permettre de travailler à la vitesse qu'il souhaite uniquement lorsque c'est nécessaire. Et il possède aussi des paramètres de "fréquences maximale" pour l'allumage et l'extinction de l'écran. Par exemple, lorsque l'écran s'allume, le CPU grimpe instantanément à la fréquence idéale choisie (par défaut 500MHz), et quand il s'éteint, le CPU descend à la fréquence idéale pour l'écran éteint (par défaut 200MHz). Ce gouverneur est un des favoris actuels car il est un bon compromis entre autonomie et performances.


Intellidemand: Encore une variante de l'Ondemand. Mais cette fois, contrairement à tous les autres gouverneurs, ce n'est pas le CPU qui sert de référence, mais le GPU ! Quand il est chargé, comme l'Ondemand il va grimper à la fréquence maximale. Quand il est au repos, ce gouverneur va fixer une fréquence maximale (selon l'appareil et le kernel installé) afin d'économiser de l'énergie.

Lazy: Encoooooooore un gouverneur basé sur l'Ondemand! :lol: Celui-ci à pour objectif d'éliminer les changements de fréquences répétés de l'Ondemand, ce qui consomme de la batterie, Du coup, il intègre une option personnalisable qui définit le temps minimum où le CPU peut être à cette fréquence-ci. De plus, Lazy intègre également un autre paramètre définissant la fréquence maximale lorsque l'écran est éteint.

Lagfree: Un basé sur, devinez qui? L'Ondemand ! (Quel succès ! ^^) La principale différence est la gestion de la batterie. La fréquence grimpe et descend par paliers, lentement. Contrairement à l'Ondemand, qui lui, grimpe souvent à 100%. Lagfree ne saute AUCUN palier, l'inconvénient à ceci est un léger lag pouvant apparaître lorsqu'une tâche lourde apparaît (par exemple à l'ouverture d'une vidéo).

Lionheart: Il s'agit d'un gouverneur basé sur le Conservative, et sur les sources de l'update3 de Samsung. Cependant, il est plus proche d'un Performance que d'un Conservative. Les changements de fréquences sont rapides et très brusques, au détriment de la batterie.
LionheartX: Un Lionheart possédant quelques changements et qui introduit un mode Suspendu pour l'écran éteint, inspiré du Smartass.

Brazilianwax: Inspiré du Smartass V2, mais plus agressif que ce dernier. Cela résulte donc de performances améliorées, mais c'est moins économe pour la batterie.

SavagedZen: Aussi issu du SmartassV2, mais moins agressif que le Bratilianwax. Il est donc plus équilibré entre performances et autonomie.

Powersave: Un gouverneur facile a comprendre, il reste à la fréquence minimale, il ne monte jamais. Bien que cela peut paraître économe lorsque l'écran est éteint, détrompez-vous ! L'appareil peut, des fois, ne plus se rallumer, il faut donc le redémarrer.

Minmax: Pas bien compliqué à comprendre non plus, ce gouverneur va soit à la fréquence minimale, soit à la fréquence maximale. Sans paliers.

Performance: Contrairement au Powersave, Performance bloque à la fréquence maximale. Ce gouverneur serait utile uniquement pour des benchmarks.

C'est cool, ça, mais maintenant, après avoir lu ce gros pavé ( :mrgreen: ), je choisis lequel?
Si le but est la performance, choisissez un LionheartX, Brazilianwax, ou encore un SavagedZen, mais l'autonomie sera relativement faible qu'à la base ! Les gouverneurs possédant un meilleur équilibre sont le Luzlactive V2 ou le Smartass V2.

Okay, mais comment je fais pour l'appliquer ?
Le plus courant serait d'utiliser un fichier init.d. Mais je vous recommende d'utiliser l'application fournie avec votre kernel (s'il y en a une), ou SetCPU. Car ils indiquent quels gouverneurs/Ordonnanceurs sont compatibles avec votre kernel, et ces applis sont simple d'utilisation !

Avec les profils SetCPU, j'ai mis un gouverneur pour l'écran allumé, et un autre pour l'écran éteint... Pourquoi mon téléphone plante et ne se rallume plus jusqu'à que je le redémarre ?
Ceci arrive lorsque vous avez utilisé deux gouverneurs intégrant des options pour l'écran éteint.

J'ai configuré un gouverneur très économe, mais comment économiser d'avantage ?
Déjà, ne pas faire d'OC, un UC serait plus judicieux, ainsi qu'un petit UV (genre -25MHz, ou moins ^^)


--- ORDONNANCEURS MÉMOIRE ---

Commençons par quelques informations.

À quoi sert donc un ordonnanceur mémoire ?
Il sert à répartir les accès mémoire entre les différents processus. Son role:
- Minimiser les temps de latende de recherche sur le disque
- Faire que les processus en premier-plan soient prioritaires par rapport aux processus de fonds.
- Garantir des délais pour chaque tâche

Il doit également:
- Permettre à tous d'accéder à la mémoire
- Optimiser les read/write en fonction du processus et du disque
- Avoir les délais les plus courts possibles.
Cependant, il est impossible d'avoir ces 3 optimisations en même temps, c'est pourquoi aucun n'est vraiment parfait, tout dépend de votre utilisation.


Noop: Il exécute chaque requête dans l'ordre. Le premier arrivé est le premier servi ! Cela peut sembler très bien, mais cela ne l'est pas, par exemple pour les PCs Linux, qui ont des disques durs avec des mouvements mécaniques à prendre en compte. Mais pour nos téléphones, possédant des stockages flash, cela n'est pas important.
AvantagesInconvénients
- Léger en CPU, donc économe pour la batterie

- Adapté au SSD (stockage flash) de nos téléphones

- Bon pour les bases de données
- Réduit le nombre de cycles CPU, ce qui baisse les performances

Deadline: Son but est d'être le plus rapide possible. Pour cela, il utilise 5 files d'attentes, dans lesquelles il classe agressivement les processus en attente.

AvantagesInconvénients
- Très rapide, surtout pour les lecture/écriture

- Le meilleur pour les SSD

- Le meilleur pour les bases de données
- En cas de grosses charges de travail, on ne peut plus savoir qui est prioritaire, qui n'aura pas accès à la mémoire à temps

CFQ: L'ordonnanceur de base. Il possède une file d'attente par processus et répartit équitablement les accès mémoire.

AvantagesInconvénients
- Performances équilibrées entre lecture et écriture

- Personnalisable

- Très bon pour les bases de données

- Excellent pour les CPUs multi-cœur
- Les processus longs le seront encore plus à cause du principe d'équité du CFQ, ne possédant pas de priorités

- Plus lent que tous les autres ordonnanceurs

BFQ: Plutôt que de se baser sur le temps que prend les processus, le BFQ se base sur combien de "secteurs disque" les processus accèdent.

AvantagesInconvénients
- Très bon pour les transferts USB

- Précis, et rapide, environ 30% plus rapide que le CFQ
- Mauvais en benchmarks (d'accord, c'est pas important... ^^)

- Quelques lags peuvent survenir lorsque un processus utilise beaucoup de secteurs disque.

SIO: Ordonnanceur mémoire simple, ne possédant pas de files d'attente, juste le principe de fusion des processus. Il ne réorganise aucune requête.

AvantagesInconvénients
- Simple et très fiable

- Minimise les manques de mémoire
- Lectures un peu plus longues que les autres ordonnanceurs, cependant, c'est quasiment peu visible.

VR: Ordonnanceur n'ayant pas de files d'attentes, il choisit le prochain processus par rapport à la "distance" de celui d'avant.

AvantagesInconvénients
- Très bon en benchmark

- Dans les situations "propices", c'est le meilleur
- Le moins fiable

- Performances moyennes

Anticipatory: Cet ordonnanceur se base sur le fait que les accès disques sont assez lents, et qu'il y a toujours des lectures, et il y a des écritures aléatoires. Donc, il rend prioritaires les lectures par rapport aux écritures.

AvantagesInconvénients
Requêtes de lecture jamais en manque d'accès

- Aussi bon que NOOP pour les SSD
- Anticipation pas toujours fiable

- Performances d'écriture réduites sur les SSD rapides.

D'accord, mais lequel est le meilleur ?
Tous, cela dépend de votre utilisation, par exemple, si vous utilisez votre téléphone pour téléphoner, et rien d'autre. Il faut donc de l'autonomie, de la rapidité et de la stabilité/fiabilité, les meilleurs sont le SIO et le NOOP pour cela.

Et comment les appliquer ?

Encore une fois, avec les applis comme SetCPU.
Ou via un script init.d:
echo "ORDONNANCEUR" > /sys/block/mmcblk0/queue/scheduler


--- SCRIPTS INIT.D ---

Qu'est-ce que c'est ?

Déjà, il faut savoir que Android boote comme ceci:

- Il y a le bootloader, qui amorce la suite
- Le kernel, qui lance les drivers, et établit le contact avec le matériel (écran, boutons, etc.)
- Les programmes utilisateurs se lancent.

L' init.d est donc utilisé à la 3ème étape.

Pour la plupart des kernels, il faut le placer dans /system/etc/init.d

Et comment en créer un ?

Il vous suffit de suivre mon tutoriel. :smile:

- - -

Merci d'avoir lu ce big tuto, et à bientôt pour de nouvelles aventures ! :smile:
N'hésitez pas si vous avez des questions, ou juste si vous aimez ce tutoriel ! Ça me fait plaisir, j'y ai passé au moins 3 heures :lol:
 
yannickamet

yannickamet

Membre VIP
Inscrit
7 Janvier 2013
Messages
6 209
Points
36
  • #2
Salut

merci pour le partage...
 
Haut Bas