Je vois au moins deux choses qu'ils manquent aujourd'hui au noyau Linux et sur lesquels personnes ne travaillent a ma connaissance.
La premiere chose, c'est la collaboration user-space/kernel space quand le systeme est sous pression memoire. Typiquement le comportement actuel est de ne jamais marquer une page memoire comme etant libere dans une application, mais de se baser sur le fait que si une page n'est plus utilise, on peut la swapper. Resultat on copie globalement des pages inutiles dans la swap... et cela impact les performances. Il serait nettement plus malin de pouvoir marquer des pages memoires comme sans importance pour l'user space de maniere a ce que le kernel puisse les jeter. Pour cela, il y a un patch actuellement en developpement, mais pas encore upstream. Meme si cela ameliorerait la situation, il resterait le cas ou tout le systeme commence a etre short niveau memoire. A ce moment la, les applications pourraient, de maniere cooperative, vider leur cache si elles ne sont pas active. Enfin en derniere recour, elle pourrait decider de s'arreter completement avant que l'OOM ne decide de les tuer, plutot que de faire un arret a l'arrache. Pour ces deux derniers cas, il n'y a pas a ma connaissance de travaux upstream sur le sujet (Android a une implementation partielle de ce genre d'idee).
Le deuxieme endroit qui necessite des ameliorations, c'est le scheduling. Le noyau est completement aveugle a ce qui va se passer dans l'espace utilisateur. Il joue au devinette en esperant que ce qui s'est passe dans le passe va se repeter a court terme. C'est un peu domage, car les applications, elles savent ce qu'elles vont faire. Or dans un systeme moderne, le scheduling est devenu tres complique. Frequence et nombre de coeur actif variable. Characteristique des coeurs differentes. Difference de bande passante memoire, IO et CPU tres grande. Ce qui rend le boulot d'un scheduler assez impossible. Android a un scheduler un peu different maintenant, au lieu d'ajuster au fur et a mesure la charge, facon TCP, il fait un gros burst des qu'on lui en demande un petit peu et redescend progressivement (en frequence et coeur). Cela permet d'avoir une reactivite plus grande aux actions de l'utilisateurs. Mais cela n'est pas forcement optimal d'un point de vue energie. A quoi cela peut-il servir de demarrer un nouveau coeur, si on a une tache qui va etre bloque par les IO.
La solution est "assez" simple, il faut que l'espace utilisateur donne l'information au kernel. Si le kernel peut savoir qu'il a des taches IO bound, memory bound ou CPU bound, il a alors une information nettement plus pertinente sur le futur et peux demarrer de maniere efficace avec la bonne frequence les coeurs qui sont necessaire avec une meilleur probabilite de reussite. Cela necessite de modifier la libc pour exposer un nouvel attribut sur les threads et aussi les process. Ensuite la majorite des operations sont maintenant fait par des toolkits comme Qt, les EFL voir meme la SDL et cela limite donc les endroit a modifier pour prendre avantage d'une telle solution.
Voila, juste une petite liste d'idee de chose qui pourrait etre ameliore niveau user space et aurait un impact direct sur l'utilisation de tous les jours de ton PC. Avoir une machine plus reactive meme quand elle est charge et qui tire meilleur partie de sa batterie et de ses processeurs, ca serait pas mal comme amelioration, non ?
[^] # Re: bof ?
Posté par cedric . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 10.
Je vois au moins deux choses qu'ils manquent aujourd'hui au noyau Linux et sur lesquels personnes ne travaillent a ma connaissance.
La premiere chose, c'est la collaboration user-space/kernel space quand le systeme est sous pression memoire. Typiquement le comportement actuel est de ne jamais marquer une page memoire comme etant libere dans une application, mais de se baser sur le fait que si une page n'est plus utilise, on peut la swapper. Resultat on copie globalement des pages inutiles dans la swap... et cela impact les performances. Il serait nettement plus malin de pouvoir marquer des pages memoires comme sans importance pour l'user space de maniere a ce que le kernel puisse les jeter. Pour cela, il y a un patch actuellement en developpement, mais pas encore upstream. Meme si cela ameliorerait la situation, il resterait le cas ou tout le systeme commence a etre short niveau memoire. A ce moment la, les applications pourraient, de maniere cooperative, vider leur cache si elles ne sont pas active. Enfin en derniere recour, elle pourrait decider de s'arreter completement avant que l'OOM ne decide de les tuer, plutot que de faire un arret a l'arrache. Pour ces deux derniers cas, il n'y a pas a ma connaissance de travaux upstream sur le sujet (Android a une implementation partielle de ce genre d'idee).
Le deuxieme endroit qui necessite des ameliorations, c'est le scheduling. Le noyau est completement aveugle a ce qui va se passer dans l'espace utilisateur. Il joue au devinette en esperant que ce qui s'est passe dans le passe va se repeter a court terme. C'est un peu domage, car les applications, elles savent ce qu'elles vont faire. Or dans un systeme moderne, le scheduling est devenu tres complique. Frequence et nombre de coeur actif variable. Characteristique des coeurs differentes. Difference de bande passante memoire, IO et CPU tres grande. Ce qui rend le boulot d'un scheduler assez impossible. Android a un scheduler un peu different maintenant, au lieu d'ajuster au fur et a mesure la charge, facon TCP, il fait un gros burst des qu'on lui en demande un petit peu et redescend progressivement (en frequence et coeur). Cela permet d'avoir une reactivite plus grande aux actions de l'utilisateurs. Mais cela n'est pas forcement optimal d'un point de vue energie. A quoi cela peut-il servir de demarrer un nouveau coeur, si on a une tache qui va etre bloque par les IO.
La solution est "assez" simple, il faut que l'espace utilisateur donne l'information au kernel. Si le kernel peut savoir qu'il a des taches IO bound, memory bound ou CPU bound, il a alors une information nettement plus pertinente sur le futur et peux demarrer de maniere efficace avec la bonne frequence les coeurs qui sont necessaire avec une meilleur probabilite de reussite. Cela necessite de modifier la libc pour exposer un nouvel attribut sur les threads et aussi les process. Ensuite la majorite des operations sont maintenant fait par des toolkits comme Qt, les EFL voir meme la SDL et cela limite donc les endroit a modifier pour prendre avantage d'une telle solution.
Voila, juste une petite liste d'idee de chose qui pourrait etre ameliore niveau user space et aurait un impact direct sur l'utilisation de tous les jours de ton PC. Avoir une machine plus reactive meme quand elle est charge et qui tire meilleur partie de sa batterie et de ses processeurs, ca serait pas mal comme amelioration, non ?