Tu écris :
>>Un thread est exécuté seulement si aucune thread de priorité supérieure n'a besoin du CPU. Le noyau linux est le dernier sur la liste.
Ca, c'est le round robin, et c'est dans l'élection de la tâche qu'on va pouvoir travailler : Comment se fait-il qu'une tâche soit élue, l'algo est-il conflictuel, élictif, queued, feedback-queued, un peu comme nos propres élections démocratiques directes proportionelles?
La façon dont RT-Linux semble fonctionner est très proche du micro-noyau : Toutes les tâches au même niveau (c'est à dire dans l'espace noyau), cela ne revient-il pas au même que pas de schisme noyau/utilisateur, comme si il n'y avait pas de protection mémoire ?
Tu dis aussi que le quantum est à 15ms, sur un Amiga/Executive2 (l'excellence du multi-tâche) on peut le régler entre 1 et 256ms, il est par défaut à 4ms, ce qui garanti des réactions très rapides, au risque de sauter une interrupt.
Là aussi il me semble qu'il faut hacker ce truc.
Si FreeBSD a un scheduler de qualité (feedback) je proposerais cette alternative, Linux me semble exagéré pour ce genre d'appli, seule sa politique de licences peut être un gain. En apparté, ce n'est pas une provocation anti-Linux, je pense aussi que Linux va avoir du mal à accrocher le desktop à cause de telles techniques : La formule noyau-monolythique round-robin n'est pas adaptée aux applications légères mais à des processus hyper-costauds dont je doute que l'utilisateur surfeur ou gamer se préoccupe.
Dans ce cas, RT-Linux pourrait être une voie à étudier, si tant est qu'on se débarasse du noyau Linux et qu'on ne laisse que l'exécutif de RT-Linux. Mais on obtient ce qu'on nomme déjà QNX.
Ne connaissant pas assez bien les arcanes mineures de Linux, je fais quelques suppositions que j'aimerais voir vérifiées ou infirmées par des kernel-hackers, d'autant que je peux reproduire les différents environnements sur ma machine, qui, vous l'aurez compris n'est ni un PC-x86, ni Linux.
[^] # Re: précisions sur RTLinux
Posté par Anonyme . En réponse à la dépêche Fujitsu va mettre en vente HOAP-1. Évalué à 0.
>>Un thread est exécuté seulement si aucune thread de priorité supérieure n'a besoin du CPU. Le noyau linux est le dernier sur la liste.
Ca, c'est le round robin, et c'est dans l'élection de la tâche qu'on va pouvoir travailler : Comment se fait-il qu'une tâche soit élue, l'algo est-il conflictuel, élictif, queued, feedback-queued, un peu comme nos propres élections démocratiques directes proportionelles?
La façon dont RT-Linux semble fonctionner est très proche du micro-noyau : Toutes les tâches au même niveau (c'est à dire dans l'espace noyau), cela ne revient-il pas au même que pas de schisme noyau/utilisateur, comme si il n'y avait pas de protection mémoire ?
Tu dis aussi que le quantum est à 15ms, sur un Amiga/Executive2 (l'excellence du multi-tâche) on peut le régler entre 1 et 256ms, il est par défaut à 4ms, ce qui garanti des réactions très rapides, au risque de sauter une interrupt.
Là aussi il me semble qu'il faut hacker ce truc.
Si FreeBSD a un scheduler de qualité (feedback) je proposerais cette alternative, Linux me semble exagéré pour ce genre d'appli, seule sa politique de licences peut être un gain. En apparté, ce n'est pas une provocation anti-Linux, je pense aussi que Linux va avoir du mal à accrocher le desktop à cause de telles techniques : La formule noyau-monolythique round-robin n'est pas adaptée aux applications légères mais à des processus hyper-costauds dont je doute que l'utilisateur surfeur ou gamer se préoccupe.
Dans ce cas, RT-Linux pourrait être une voie à étudier, si tant est qu'on se débarasse du noyau Linux et qu'on ne laisse que l'exécutif de RT-Linux. Mais on obtient ce qu'on nomme déjà QNX.
Ne connaissant pas assez bien les arcanes mineures de Linux, je fais quelques suppositions que j'aimerais voir vérifiées ou infirmées par des kernel-hackers, d'autant que je peux reproduire les différents environnements sur ma machine, qui, vous l'aurez compris n'est ni un PC-x86, ni Linux.