ce qu’il faudrait, ce serait pouvoir choisir l’algo qu’on veut lors de la compilation. Par exemple, un algo plus adapté pour les lourdes charges sur un serveur ou un machine chargée de faire du calcul intensif, et un autre plus adapté pour des trucs légers comme la bureautique ou pour le mutimedia.
fakbill:
Techniquement on peut changer l’algo de schedulling lorsque la charge augmente… Mais je ne pas sûr que l’on gagne quoique ce soit : le problème est que faire des tâches en cours d’exécution? Car il ne faut pas que le changement de d’algo soit plus coûteux que de conserver un algo, même si celui que l’on garde n’est pas trop adapté à la charge…
Et pour le savoir il faudrait par exemple faire de l’anticipation de charge que l’on va avoir (faire des stats)… car on pourrait très bien avoir quelques pics au dessus de la limite de charge à partir de laquelle changer l’algo, et non une augmentation durable de la charge.
CE n’est pas évident à implementer dans le noyau!
Et encore, là on ne prend que le cas d’un mono processeur. Si on commence à avoir des migrations de tâches entre CPU, et que les algos eux mêmes sont en cours de modification, il ne faut pas arriver à des blocages, ni à des pertes de données… et gagner du temps sur un algo simple comme du rr
Pour ce qui est des algos de vmm, on peut déjà les choisir à la compilation suivant les seuils
1 algo pour la Mémoire <= 800Mo
1 algo pour 800<M<= 2Go
1 algo pour 2Go<64Go
Maintenant on peut toujours faire (ou on pourra faire?) du hotplug sur de la mémoire, par exemple sur des machines virtualisées, et là les mêmes problèmes d’optimisations apparaissent que pour les cpus et la charge?
Oui oui tu sais je disais ça comme ça 
C’est sûr que le passage d’un algo à l’autre risque d’être couteux et les prédictions quasi impossibles (sauf à très court terme et encore…on risque d’y perdre). Mais au fait, j’y repense…sur la lkml, on a vu passer des algo type rr qui ajustent les time slices en fonction de ce que le processus a pris comme ressources au tour d’avant. En résumé, c’était du genre : “tu es gourmand, je t’en donne plus au prochain coup. T’as rien mangé, t’en aura moins”. C’était il y a déjà longtemps…pendant le dévelo du 2.5. Je ne sais pas ce que c’est devenu. Le problème évident est de faire en sorte que les gros processus ne trustent pas les resources. Arff…on peut parler de ça longtemps sans faire bcp avancer la question.
Pour ce qui est du multi-proc, je suis d’accord : La moindre idée devient vite une horreur à finaliser du fait de toutes les sources de blocages possibles.
http://marc.theaimsgroup.com/?l=linux-kernel&m=109163229922366&w=2
Zut alors, voila que Linus se mets à intégrer des patchs qui posent des pbs de licence. Peut on mélanger du BSD et du GPL dans un même projet?
fakbill, qui a renoncé à savoir écrire correctement “licen’c|s’e” en français et en anglais
Heu… si on met du BSD dans du GPL on obtient du GPL… ceci dit… il y a bcp bcp de code partagés entre les BSD et les GPL… à quelques détails prêts.
Le problème évident est de faire en sorte que les gros processus ne trustent pas les resources. Arff…on peut parler de ça longtemps sans faire bcp avancer la question.
Ca c’est clair… A moins de passer au code et aux tests, difficile d’imaginer ce qui marcherai le mieux
Le type n’a pas l’air de vouloir que son code sous BSD passe sous GPL. A t il le droit d’interdire ça? Tu dis qu’on peux faire cohabiter les deux alors de quoi se plaint il?
Pour ce que est du scheduler, on est d’accord : On arrete d’user les claviers à parler de la question
Tiens, un log suspect avec le 2.6.8-rc3 :
[fixed]ReiserFS: hda3: warning: vs-8301: reiserfs_kmalloc: allocated memory 201892[/fixed]
Très bon lien merci 
En résumé, le nouveau scheduler est “mieux” que celui de la branche principale mais il a toujours de gros problèmes à gérer certains cas de figure. On peut toujuors rajouter des heuristiques (du style “si on dans ce cas là, execptionnellement fait cela”) mais le scheduler de la branche principale semble avoir un comportement “plus lisse.”
Andrew Morton noted, “I don’t expect we’ll be merging a new CPU scheduler into mainline any time soon, but we should work to understand where this improvement came from, and see if we can get the mainline scheduler to catch up.”
fakbill : l’interdire je ne vois pas comment car la licence BSD explique clairement que l’on peut merger le code BSD dans un code sous une autre licence.
D’ailleurs le code NFS fut à l’origine inspiré de FreeBSD, et le code NFSv4 est repris sur … openBSD (qui est sous GPL)
Sinon même avec des heuristiques ce n’est pas évident… voire pas logique, car on commence à en mettre 1 et on se retrouve avec un moteur d’IA dans le noyau 
… encore que faire du recuit simulé pour déterminer les meilleures perfs… sans rien dégrader…
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8-rc3/2.6.8-rc3-mm1/announce.txt
jé failli le laisser passer celui là, il est arrivé depuis hier déjà
v_atekor : Pour les licences ont est d’accord. Tu as vu la réponse de Linus : Le status de ce code n’est en fait pas très clair à la base d’ou où le pb.
Pour reparler du scheduler, c’est clair que je trouve qu’un algo simple (ie sans cas particulier) est plus beau que n’importe quoi d’autre. Cela dit, ce n’est qu’une opinion esthétique
ps : tu veux pas un algo génétique non plus lol
2.6.8-rc3-mm1 :
“Dropped the staircase scheduler, mainly because the schedstats patch broke it.
We learned quite a lot from having staircase in there. Now it’s time for a new scheduler anyway.”
Andrew a donc l’air de vouloir un nouveau scheduler…
2.6.8-rc3-mm2 :
-
Added a little patch to the CPU scheduler which disables its array
switching.This is purely experimental and will cause high-priority tasks to starve
lower-priority tasks indefinitely. It is here to determine whether it is
this aspect of the scheduler which caused the staircase scheduler to exhibit
improved throughput in some tests on NUMAq. -
If some devices mysteriously stop working, try booting with pci=routeirq.
If that fixes it, please send a report, Cc’ing bjorn.helgaas@hp.com. See
remove-unconditional-pci-acpi-irq-routing.patch
je vais le compiler pour voir
edit: erreurs lors de la compilation, fonctionne si je désactive le SMP
http://marc.theaimsgroup.com/?l=linux-kernel&m=109210717300709&w=2
et comme Andrew est très rapide :
http://marc.theaimsgroup.com/?l=linux-kernel&m=109212286719221&w=2
2.6.8 dans les bacs =)
2.6.8 :
"
The major patches since -rc4 were some sparc64 and parsic updates, but
there’s some network driver and SATA updates and a few ARM patches too.
And a use-after-free fix in MTD."
Par encore de réactions sur la lkml.
Allez hop, au boulot