Clairement le scheduler du noyau Linux a plus d'un probleme. Un des sujets non aborde dans l'article, qui est tres interressant. C'est les problemes de consommation d'energie et de scheduling lie a cela. Typiquement sur les taches interactives fonctionnant avec un device sur batterie, le scheduler est globalement toujours faux.
Le principe du scheduler est de regarder le passe d'une tache pour en deviner son usage futur. Le probleme des taches interactives, c'est que par design le process principal fait un peu de tout a une frequence eleve (Hop, une IO, un peu de CPU bound pour calculer le nouveau layout, puis un peu de memory bound pour regarder si il y a des trucs a dessigner, ...). Il devient assez evident que ce qu'une tache a fait dans le passe aide peu.
La solution evidente, c'est de creer plusieurs process/thread qui chacun doit faire un seul truc. Meme si ils ne sont pas execute en parallele et si ils consomment plus de RAM, au final, le noyau devrait etre capable de scheduler tout ca de maniere plus efficace... Sauf que non, pour tout un tas detail, qu'on peut resumer a la non integration de cpufreq et cpuidle dans le scheduler, le noyau est incapable d'utiliser les ressources du materiel de maniere optimal. On se retrouve alors avec des gros hack pas beau. Comme par exemple sur certain telephone ou un process en tache de fond regarde quel est l'application active et change les parametres de frequence et du nombre de CPU en fonctionnement pour avoir un resultat un peu plus optimal... Gros hack, franchement pas terrible.
Tout ca pour dire que sans le boulot en court du scheduler energy aware, et bien, on a encore de la marge... Oh, et bien entendu, l'user space doit aussi s'adapter ! On a encore du boulot pour quelques annees...
# Le scheduler, il est a l'ouest !
Posté par cedric . En réponse au journal Linux: une décennie de coeurs gaspillés. Évalué à 6.
Clairement le scheduler du noyau Linux a plus d'un probleme. Un des sujets non aborde dans l'article, qui est tres interressant. C'est les problemes de consommation d'energie et de scheduling lie a cela. Typiquement sur les taches interactives fonctionnant avec un device sur batterie, le scheduler est globalement toujours faux.
Le principe du scheduler est de regarder le passe d'une tache pour en deviner son usage futur. Le probleme des taches interactives, c'est que par design le process principal fait un peu de tout a une frequence eleve (Hop, une IO, un peu de CPU bound pour calculer le nouveau layout, puis un peu de memory bound pour regarder si il y a des trucs a dessigner, ...). Il devient assez evident que ce qu'une tache a fait dans le passe aide peu.
La solution evidente, c'est de creer plusieurs process/thread qui chacun doit faire un seul truc. Meme si ils ne sont pas execute en parallele et si ils consomment plus de RAM, au final, le noyau devrait etre capable de scheduler tout ca de maniere plus efficace... Sauf que non, pour tout un tas detail, qu'on peut resumer a la non integration de cpufreq et cpuidle dans le scheduler, le noyau est incapable d'utiliser les ressources du materiel de maniere optimal. On se retrouve alors avec des gros hack pas beau. Comme par exemple sur certain telephone ou un process en tache de fond regarde quel est l'application active et change les parametres de frequence et du nombre de CPU en fonctionnement pour avoir un resultat un peu plus optimal... Gros hack, franchement pas terrible.
Tout ca pour dire que sans le boulot en court du scheduler energy aware, et bien, on a encore de la marge... Oh, et bien entendu, l'user space doit aussi s'adapter ! On a encore du boulot pour quelques annees...