Je bosses sur les EFL, toolkit graphique, on fonctionne avec un systeme pour l'instant avec uniquement 2 threads la majorite du temps (main loop et thread de rendu). Le fait est qu'il y a un certain nombre de probleme observable avec le "scheduler" actuel.
Ainsi lorsque l'utilisateur n'a pas interagit avec la machine pendant quelques secondes et se met a faire une action importante (cas normal de je lis ce qui est a l'ecran avant de passer a un autre ecran), on se retrouve a avoir un enorme frame drop du fait que tous les coeurs sont globalement au repos, et qu'ils sont incapable d'accelerer instantanement tous en meme temps. Si on force a la frequence maximum et tous les coeurs allumes, il n'y a pas de souci. Or le toolkit sait quand il va rendre une frame, il sait dire a ce moment la qu'il va etre dans un premier temps CPU bound sur la traverse du scene graph et le calcul de ce qui doit etre dessine avant d'avoir un mix de CPU et memory bound en fonction des operations de rendu qu'il va faire (en GL, ca sera majoritairement du memory bound et on a un interet a avoir les deux threads schedule sur deux coeurs differents pour qu'ils puissent beneficier de tout le L1 possible).
Et bien entendu quand le CPU est enfin completement reveille, il est trop tard. L'animation est fini et tout ce qu'il a appris du passe est juste plus d'actualite ! On se retrouve donc dans une situation ou tous les coeurs sont enfin allume et la frequence au maximum, mais on n'a plus rien a faire. Echec total du scheduler et utilisateur ayant l'impression d'avoir un hardware incapable de gerer son application.
D'ou l'interet de permettre a l'user space de dire au kernel ce qu'il se passe. On sait ce qui va se passer, on sait combien de temps notre animation va durer. De plus, si on avait une telle infrastructure, ca vaudrait le cout d'augmenter le nombre de thread en les specialisant encore plus. On pourrait tirer clairement mieux parti du hardware si le kernel et l'user space communique un peu plus. Il ne faut pas oublier qu'un toolkit moderne fournit toutes les primitives d'acces aux systemes graphiques et IO ainsi qu'une certaine abstraction des threads. Il est donc possible que dans la majorite des cas, le fait de juste integrer ces hints dans le toolkit soit suffisant pour avoir un benefice notable.
L'alternative moins elegante est celle d'Android. Elle consiste a toujours refuser le dialogue avec l'user space et a faire un scheduling ou on boost le CPU au moment d'une phase interactive. Je ne trouve pas cette solution elegante, car le systeme va faire une pointe de consomation d'energie qui n'est probablement pas necessaire (et plus on aura de coeurs, plus cette pointe risque d'etre surdimensionne).
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 10.
Je bosses sur les EFL, toolkit graphique, on fonctionne avec un systeme pour l'instant avec uniquement 2 threads la majorite du temps (main loop et thread de rendu). Le fait est qu'il y a un certain nombre de probleme observable avec le "scheduler" actuel.
Ainsi lorsque l'utilisateur n'a pas interagit avec la machine pendant quelques secondes et se met a faire une action importante (cas normal de je lis ce qui est a l'ecran avant de passer a un autre ecran), on se retrouve a avoir un enorme frame drop du fait que tous les coeurs sont globalement au repos, et qu'ils sont incapable d'accelerer instantanement tous en meme temps. Si on force a la frequence maximum et tous les coeurs allumes, il n'y a pas de souci. Or le toolkit sait quand il va rendre une frame, il sait dire a ce moment la qu'il va etre dans un premier temps CPU bound sur la traverse du scene graph et le calcul de ce qui doit etre dessine avant d'avoir un mix de CPU et memory bound en fonction des operations de rendu qu'il va faire (en GL, ca sera majoritairement du memory bound et on a un interet a avoir les deux threads schedule sur deux coeurs differents pour qu'ils puissent beneficier de tout le L1 possible).
Et bien entendu quand le CPU est enfin completement reveille, il est trop tard. L'animation est fini et tout ce qu'il a appris du passe est juste plus d'actualite ! On se retrouve donc dans une situation ou tous les coeurs sont enfin allume et la frequence au maximum, mais on n'a plus rien a faire. Echec total du scheduler et utilisateur ayant l'impression d'avoir un hardware incapable de gerer son application.
D'ou l'interet de permettre a l'user space de dire au kernel ce qu'il se passe. On sait ce qui va se passer, on sait combien de temps notre animation va durer. De plus, si on avait une telle infrastructure, ca vaudrait le cout d'augmenter le nombre de thread en les specialisant encore plus. On pourrait tirer clairement mieux parti du hardware si le kernel et l'user space communique un peu plus. Il ne faut pas oublier qu'un toolkit moderne fournit toutes les primitives d'acces aux systemes graphiques et IO ainsi qu'une certaine abstraction des threads. Il est donc possible que dans la majorite des cas, le fait de juste integrer ces hints dans le toolkit soit suffisant pour avoir un benefice notable.
L'alternative moins elegante est celle d'Android. Elle consiste a toujours refuser le dialogue avec l'user space et a faire un scheduling ou on boost le CPU au moment d'une phase interactive. Je ne trouve pas cette solution elegante, car le systeme va faire une pointe de consomation d'energie qui n'est probablement pas necessaire (et plus on aura de coeurs, plus cette pointe risque d'etre surdimensionne).