Eric Lacombe a écrit 11 commentaires

J'ai bien écris un article sur le scheduler de Linux dans Lmag, mais il ne pousse pas suffisamment dans le détail. Je te conseille de regarder le book "Understanding the Linux Kernel" dans ça 3° édition, de fouiller également dans le code car il n'est plus tout à fait à jour (le livre se fonde sur un 2.6.12). Mais bon la grande majorité des choses n'ont pas changées ;)

Il y a également cela (2.6.8.1): http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf

Par "prio forte" je voulais signifier "les tâches dont l'échéance est la plus proche" (bien que ce ne soit pas forcément tjs le cas). Je ne mentionnais pas de méthode ou d'implémentation. Mais il est vrai que ma phrase était maladroite...

Quand j'ai employé "prio forte", c'était en fait pour parler des tâches dont l'échéance était la plus proche (même si c'est pas toujours le cas en fait ;). Je ne faisais pas de supposition sur la méthode employée. Ma phrase est cependant maladroite, c'est vrai...

Fouille sur les archive de la LKML.
(je te rappelle également que la valeur par défaut sur 2.6 est depuis déjà qq temps, positionnée à 250Hz).

Eric L : >>Le noyau de Linux est préemptible (avec l'option qui va bien selectionnée lors de la config)
-> il ne s' agit pas de la même chose, je pense que tu le sais. C' est un module temps-réel (un linux security module) ce qui est différent d' un kernel preemption on acid

Quand je disais ça je répondais uniquement à Christophe Cazajus :

tous les appels système pourront
être préempté - ce qui est loin d'être le cas actuellement.

-----------------

Sinon quand tu dis "un module temps-réels (un linux security module)", il n'y a strictement aucun rapport entre un LSM et le temps réel.
La péemption en mode noyau est une caractérisque commune aux noyaux RT. Les patchs de Love, Morton, permettent justement cela (on a soit un appel direct au scheduler par les tâches soit c'est en sortant de certains chemins noyau (ex. retour en usermode, etc.)) que le flag NEED_RESCHED (positionné lors du traitement d'une interruption par ex) est testé et s'il est positionné, on fait appel au scheduler.). Ensuite, il y a beaucoup d'autres choses à modifier afin d'obtenir un noyau RT dur, et c'est ce à quoi se démène Ingo et Ted (préemption des spinlocks, etc.). Bref...

Le vrai terme "système temps-réel" pourrait être "système prédictible"

Ce n'est pas suffisant, il faut la propriété de déterminisme également.

Un watchdog (dont Eric L parle également ici) tournant en temps-réel se chargeant de la sécurité.

C'est un certain Christophe Cazajus qui parle de watchdog...
sinon le watchdog se charge de la sûreté de fonctionnement (safety) et _non_ de la sécurité au sens security !!!

Les deux solutions présentées par défaut dans tout kernel sont toutes des "temps-réel mous".

ben non... (par ex. VMware s'est pour du RT dur). Encore une fois, le temps réel est dit dur lorsque l'on a besoin d'avoir des _garanties_ sur les _échéances_ (Le temps de traitement peut très bien être important, ça dépend du système à piloter). Et ces dites garanties doivent être prouvées mathématiquement (RMA, etc.). Le RT mou est quant à lui adapté pour les traitements audio ou vidéo, car une garantie au sens math n'est pas nécessaire (il n'y a pas risque de mort)...

Bref, il ya beaucoup de chose à dire... En tout cas il n'y a pas d'intérêt d'avoir un Linux patché RT dur pour une station de travail (c'est hors propos)..

Le noyau de Linux est préemptible (avec l'option qui va bien selectionnée lors de la config).
Maintenant dans certaines parties la préemption est désactivée, il reste encore quelques "noyaux durs" à supprimer, mais dans l'ensemble c'est fait.

Pour avoir beaucoup de réactivité, il faut traiter les interruptions de tout au plus vite, dans ce cas tu ne peux rien garantir pour une certaine tâche en particulier (je n'ai en aucun cas mentionné des tâches périodiques qui comme tu le dis ne sont pas la seule composante des sys RT). Dans un système RT, les tâches de prio forte doivent prendre le devant. Tu ne peux pas imaginer d'avoir de la réactivité pour tout. Celle dont je parlais c'était celle que souhaite un utilisateur devant son poste de travail : réponse au plus vite aux E/S. Ce qui est d'ailleurs valorisé au sein de l'ordonnanceur de Linux.

horloge hrt à fait son apparition en juin, et qu' il -me- semble que le patch de Sir Molnar en a une aussi

Les hrtimers n'ont rien à voir avec l'horlogoge système. Pour le reste tu dois faire référence au patch dyntick d'ingo Molnar et Ted T'so.

et 1000hz bien sûr.. au fait hpet on garde ou pas ? ;)

Régler la fréquence d'horloge à 1000Hz n'est pas forcément une bonne idée car le temps passé à gérer l'interruption du timer prend une part non négligeable du temps processeur. HPET est une infrastructure très intéressante, d'ailleurs si ta CM à ce type de matos il est justement utilisé en prio (si tu l'as activé dans les options du noyau) pour l'interruption du timer...
Un truc intéressant sinon est bien le patch dyntick qui propose du tickless ou du tick variable (cependant plutôt pour le domaine de l'embarqué par rapport à la conso énergétique).

mais en realtime complet juste en recompilant (et en mettant au diapason PAM pour l' audio) = le bonheur total...

Si par realtime complet tu entends hard real time, je doute que cela soit le bonheur total pour une utilisation "poste de travail" où l'interactivité avec le système est un aspect important. Le hard RT garanti (de façon mathématique) les latences max, au détriment de l'intéractivité justement.

Rassure toi, tu as compris comme il faut ce que fait smpnice. La description donnée par patrick_g est fausse.

Heureux d'apprendre que la rubrique Kernel Corner est appréciée ;)
Le prochain KC arrive bientôt (avec deux grosses brèves cette fois) et vous comblera, je l'espère ;)

Il me semble que Krunsh parlait ici du but du rootkit. Et dans ce cas, sa phrase est tout à fait pertinente. On installe un rootkit lorsque l'on a déjà aqui des privilèges superuser (la plupart du temps) via l'exploitation d'une faille.