Desole de faire un gros tas de toutes les decisions de scheduling en mettant dedans aussi la prise de decision sur les ressources a rendre disponible pour les applications (puisque c'est globalement l'idee derriere allumer/eteindre et regler la frequence des differents coeurs). Mais bon, d'un point de vue user-space, c'est la meme problematique :-)
Aujourd'hui, le noyau est aveugle. Il n'a aucune idee de ce qu'une tache va potentiellement faire dans le futur. Des IO ? Des acces memoire ? Une utilisation intensive du CPU ? Cela a directement un impact sur les performances, la reactivite et la consomation batterie. Il y a deja des cooperations entre l'user space et le noyau, c'est juste une de plus. Bien entendu le kernel ne vas pas baser ses decisions uniquement sur ces hints sans ajuster un peu a posteriori ses decisions, mais si le systeme coopere, c'est nettement plus malin. Si un toolkit fait du rendu graphique, il va pouvoir assez facilement indiquer quel thread va etre CPU ou memory bound dans le futur. Ce que le kernel ne pourra jamais savoir ou que lorsque ce sera trop tard.
Ce n'est pas du cooperatif au sens de je relache le CPU quand j'ai fini de faire mes betises, mais du cooperatif au sens des hints qu'on met sur une page lors d'un mmap. L'idee est d'aider le noyau a prendre la bonne decision. Ca ne sert a rien d'allumer 4 coeurs pour 4 taches IO bound, par contre si elles sont CPU bound, ca serait une tres bonne idee de le faire tout de suite, et pas quand elles seront presque fini...
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 7.
Desole de faire un gros tas de toutes les decisions de scheduling en mettant dedans aussi la prise de decision sur les ressources a rendre disponible pour les applications (puisque c'est globalement l'idee derriere allumer/eteindre et regler la frequence des differents coeurs). Mais bon, d'un point de vue user-space, c'est la meme problematique :-)
Aujourd'hui, le noyau est aveugle. Il n'a aucune idee de ce qu'une tache va potentiellement faire dans le futur. Des IO ? Des acces memoire ? Une utilisation intensive du CPU ? Cela a directement un impact sur les performances, la reactivite et la consomation batterie. Il y a deja des cooperations entre l'user space et le noyau, c'est juste une de plus. Bien entendu le kernel ne vas pas baser ses decisions uniquement sur ces hints sans ajuster un peu a posteriori ses decisions, mais si le systeme coopere, c'est nettement plus malin. Si un toolkit fait du rendu graphique, il va pouvoir assez facilement indiquer quel thread va etre CPU ou memory bound dans le futur. Ce que le kernel ne pourra jamais savoir ou que lorsque ce sera trop tard.
Ce n'est pas du cooperatif au sens de je relache le CPU quand j'ai fini de faire mes betises, mais du cooperatif au sens des hints qu'on met sur une page lors d'un mmap. L'idee est d'aider le noyau a prendre la bonne decision. Ca ne sert a rien d'allumer 4 coeurs pour 4 taches IO bound, par contre si elles sont CPU bound, ca serait une tres bonne idee de le faire tout de suite, et pas quand elles seront presque fini...