Le .37 apportait déjà pas mal car on gagnait vraiment en fluidité sous forte charge mais là, avec ce patch en plus, c'est une tuerie :)
Sur mon liveusb, c'est étonnamment fluide ;)
== Explications (théorie) ==
Pour l'explication technique, c'est pas bien compliqué (c'est une supposition qui correspond bien au nom du patch).
Soit X le nombre de processus sur le système.
Sans le patch, chaque processus recevra un minimum de 100/X % du processeur.
Le problème, c'est que quand on compile avec 64 gcc, on diminue vachement le temps processeur restant pour les autres applications (qui ont besoin d'un pic de CPU, mais pas longtemps).
Donc, plutôt que d'allouer le temps processeur en fonction du nombre de processus, ce temps processeur est alloué en fonction des groupes.
Si on a un groupe GUI et un groupe compilation, 50% du temps processeur ira à la GUI et 50% ira à la compilation. Comme le groupe GUI n'a pas besoin de tout ça, l’excédant part dans les groupes qui en ont besoin :)
Et voilà comment on augmente la réactivité générale sans vraiment perdre en performance :)
PS: Il semblerait que les groupes soient définis en fonction du TTY depuis lequel il a été lancé. Comme la GUI est sur le TTY7 et que les consoles sont dans /dev/pts/, les 2 sont dans 2 groupes séparés, et on a donc un ordonnancement plus juste.
Je me demande comment le système réagira en cas de bomb fork avec ce patch, faudra que je teste à l'occaz.
# Testé et approuvé ;)
Posté par Martin Peres (site web personnel) . En réponse au journal Noël, noël, un patch miraculeux !. Évalué à 10.
Sur mon liveusb, c'est étonnamment fluide ;)
== Explications (théorie) ==
Pour l'explication technique, c'est pas bien compliqué (c'est une supposition qui correspond bien au nom du patch).
Soit X le nombre de processus sur le système.
Sans le patch, chaque processus recevra un minimum de 100/X % du processeur.
Le problème, c'est que quand on compile avec 64 gcc, on diminue vachement le temps processeur restant pour les autres applications (qui ont besoin d'un pic de CPU, mais pas longtemps).
Donc, plutôt que d'allouer le temps processeur en fonction du nombre de processus, ce temps processeur est alloué en fonction des groupes.
Si on a un groupe GUI et un groupe compilation, 50% du temps processeur ira à la GUI et 50% ira à la compilation. Comme le groupe GUI n'a pas besoin de tout ça, l’excédant part dans les groupes qui en ont besoin :)
Et voilà comment on augmente la réactivité générale sans vraiment perdre en performance :)
PS: Il semblerait que les groupes soient définis en fonction du TTY depuis lequel il a été lancé. Comme la GUI est sur le TTY7 et que les consoles sont dans /dev/pts/, les 2 sont dans 2 groupes séparés, et on a donc un ordonnancement plus juste.
Je me demande comment le système réagira en cas de bomb fork avec ce patch, faudra que je teste à l'occaz.