C'est dit, je me consacre du temps cet été pour me "muscler" au niveau du scheduler et des éléments internes du kernel. Le but : apporter une petite touche avec l'esprit temps-réel. Je ne serai pas le premier à le faire (ni le dernuer j'espère), mais ce serait tellement chouette un kernel RT...
Si quelqu'un a un pointeur pour des analyses au sujet de FreeBSD sur ce point je suis preneur :-)
lundi 20 juillet 2009
jeudi 11 juin 2009
Hors sujet
Petite parenthèse 100% hors sujet.
Dans l'actuelle mouvance philosophico-écologique, ne crachons pas sur ce qui est fait jusqu'ici, on a fait bien plus d'effort en 10 ans que pendant tout le reste de l'humanité, le tout grâce à une prise de conscience dont on finissait par désespérer.
Cependant, chassez le libéral, il revient au galop, tout s'est fait en se concentrant sur une seule donnée, puisque comme chacun sait notre monde perçu par les financiers n'existe qu'en 1 dimension... Et la dimension qui a été choisie s'appelle "CO2".
Or il est un domaine où la pollution autre que le CO2 a un aspect manifestement plus nocif et dommageable que le CO2 : les moteurs à combustion spontanée (nommés du patronyme de son inventeur "Diesel"). En effet, une étude suédoise attribue aux échappements du Diesel en Europe presuqe autant de morts par cancer du poumon que... l'amiante, interdite chez nous depuis quelques années déjà !
On pourra dire qu'il s'agit encore d'une avancée écologique, puisque les premiers touchés par les dommages en question sont les mammifères vivant en zône urbaine, à savoir les homo erectus citadinus, aussi les pires pollueurs de la planète : autorégulation...
Je n'adhère pas.
Exigeons la prise en compte des émissions de particules fines (non filtrées par les très mercantiles "Filtres à Particules") dans le calcul de la puissance fiscale et de la taxe pollution.
Dans l'actuelle mouvance philosophico-écologique, ne crachons pas sur ce qui est fait jusqu'ici, on a fait bien plus d'effort en 10 ans que pendant tout le reste de l'humanité, le tout grâce à une prise de conscience dont on finissait par désespérer.
Cependant, chassez le libéral, il revient au galop, tout s'est fait en se concentrant sur une seule donnée, puisque comme chacun sait notre monde perçu par les financiers n'existe qu'en 1 dimension... Et la dimension qui a été choisie s'appelle "CO2".
Or il est un domaine où la pollution autre que le CO2 a un aspect manifestement plus nocif et dommageable que le CO2 : les moteurs à combustion spontanée (nommés du patronyme de son inventeur "Diesel"). En effet, une étude suédoise attribue aux échappements du Diesel en Europe presuqe autant de morts par cancer du poumon que... l'amiante, interdite chez nous depuis quelques années déjà !
On pourra dire qu'il s'agit encore d'une avancée écologique, puisque les premiers touchés par les dommages en question sont les mammifères vivant en zône urbaine, à savoir les homo erectus citadinus, aussi les pires pollueurs de la planète : autorégulation...
Je n'adhère pas.
Exigeons la prise en compte des émissions de particules fines (non filtrées par les très mercantiles "Filtres à Particules") dans le calcul de la puissance fiscale et de la taxe pollution.
lundi 24 novembre 2008
La latence, tout est là...
Les efforts de Ingo Molnar ont été momentanément mis en attente avec la suppression du Big Kernel Lock apparu pour (de mémoire) le 2.6.27. Tout ça pour arriver (enfin) à maîtriser la latence.
Aujourd'hui, où en est-on exactement ? A part que la plupart des handlers se contruisent avec la problématique de latence en tête, il reste des approches contradictoires, ou plus exactement "nombrilistes" : si l'on veut que "son" driver soit temps réel à latence la plus faible alors il faut que tous les autres drivers aient une latence sous interruption maîtrisée (donc souvent en 2 parties) mais que l'on écrive son propre driver en monobloc... Rassurons-nous, la différence entre les deux reste très faible.
A voir en pratique...
Prochaine étape : tickless kernel sur OpneMoko et Pandora.
Aujourd'hui, où en est-on exactement ? A part que la plupart des handlers se contruisent avec la problématique de latence en tête, il reste des approches contradictoires, ou plus exactement "nombrilistes" : si l'on veut que "son" driver soit temps réel à latence la plus faible alors il faut que tous les autres drivers aient une latence sous interruption maîtrisée (donc souvent en 2 parties) mais que l'on écrive son propre driver en monobloc... Rassurons-nous, la différence entre les deux reste très faible.
A voir en pratique...
Prochaine étape : tickless kernel sur OpneMoko et Pandora.
jeudi 28 août 2008
FreeRunner
Ca y est, je l'ai ! un téléphone dont tout l'ensemble logiciel est en très forte majorité Open Source. Seule exception, la pile GSM, intégralement contenue dans une puce pour éviter les soucis liés au protocole (on ne va tout de même pas envoyer un faux IMSI pour faire facturer le voisin...).
Pour le reste, résolution intéressante, réactivité convenable, pas mal du tout le QTopia.
L'aspect technique ? Un kernel 2.6.22.x patché, donc pas de tickless kernel. C'est certainement un des éléments qui expliquent une autonomie faiblarde. Une saisie, basé sur un tandem clavier / dictionnaire prédictif, divise la communauté. Bref, le travail a besoin d'encore un peu de finition.
Pour le reste, résolution intéressante, réactivité convenable, pas mal du tout le QTopia.
L'aspect technique ? Un kernel 2.6.22.x patché, donc pas de tickless kernel. C'est certainement un des éléments qui expliquent une autonomie faiblarde. Une saisie, basé sur un tandem clavier / dictionnaire prédictif, divise la communauté. Bref, le travail a besoin d'encore un peu de finition.
mercredi 25 juin 2008
Première Matinale Red Hat
Hier (mardi 24/6) matin, j'ai eu l'opportunité d'être convié à une Matinale Red Hat, la première du nom en fait. Le but : présenter toutes les nouveautés de l'entreprise au Fedora rouge dans le domaine de la virtualisation, ainsi que 2 invités de marque, Intel pour montrer la participation du fondeur aux technologies de virtualisation, et un cas concret de mise en oeuvre de virtualisation, présenté par des membres de l'équipe de DSI de Pages Jaunes.
Concernant la virtualisation, à part un engagement de Red Hat avec Xen jusqu'en 2014 et des développements poussant aujourd'hui des technologies du kernel 'Vanilla', au premier chef kvm, l'accent est surtout mis sur la carence actuelle des logiciels libres de virtualisation, que j'avais identifiée avec mon collègue D. Hannequin dans le Livre Blanc publié par LINAGORA sur le sujet : les outils d'administration de parc virtuel. D'excellentes nouvelles donc.
La fin de leur présentation signalait aussi une annonce nommér MRG : Messaging Realtime Grid, basé sur Linux, série 2.6.24. La mise en avant d'un produit annoncé temps réel dur basé sur un kernel "vanilla"...
J'avais ouvert ce blog en espérant merttre en évidence que cela était en effet possible, mais le résidu de BKL (Big Kernel Locks) dans le kernel, et l'évaluation de A. Morton à environ 10 ans de travail pour s'en débarrasser totalement m'avait un peu ramené à la dure réalité : not yet.
Et toujours pas d'ailleurs, en réalité, mais qu'un des plus gros industriels impliqués dans le noyau s'y engage, c'est une excellente nouvelle. On tient les paris... Pour 2009 ?
Concernant la virtualisation, à part un engagement de Red Hat avec Xen jusqu'en 2014 et des développements poussant aujourd'hui des technologies du kernel 'Vanilla', au premier chef kvm, l'accent est surtout mis sur la carence actuelle des logiciels libres de virtualisation, que j'avais identifiée avec mon collègue D. Hannequin dans le Livre Blanc publié par LINAGORA sur le sujet : les outils d'administration de parc virtuel. D'excellentes nouvelles donc.
La fin de leur présentation signalait aussi une annonce nommér MRG : Messaging Realtime Grid, basé sur Linux, série 2.6.24. La mise en avant d'un produit annoncé temps réel dur basé sur un kernel "vanilla"...
J'avais ouvert ce blog en espérant merttre en évidence que cela était en effet possible, mais le résidu de BKL (Big Kernel Locks) dans le kernel, et l'évaluation de A. Morton à environ 10 ans de travail pour s'en débarrasser totalement m'avait un peu ramené à la dure réalité : not yet.
Et toujours pas d'ailleurs, en réalité, mais qu'un des plus gros industriels impliqués dans le noyau s'y engage, c'est une excellente nouvelle. On tient les paris... Pour 2009 ?
lundi 5 mai 2008
Latences...
Tout d'abord la référence : la programmation temps-réel a ses normes : POSIX 4d9, devenu POSIX 1003.1b-1993 puis POSIX 1003.1i-1995. Totu cela indique comment coder une application utilisateur qui se comporte d'une certaine manière et quelles sont les obligations et/ou bonnes partiques d'un OS en terme de réponse.
Du point de vue d'une application, le temps est continu, la seule chose à prendre en compte est que le temps entre deux "gettimeofday" est foncièrement indécidable. L'important donc pour un code en mode utilisateur, c'est essentiellement de pouvoir réquisitionner le processeur dans des temps bornés (réaction à sollicitation), ou en temps prévu (interval timer).
Or cette réquisition va se faire moyennant un certain délai, entièrement du ressort de l'OS : le temps d'interrompre une tâche (user ou kernel) en cours, le temps de sélectionner la tâche à éxécuter, le temps de reprendre.
Concernant la reprise, le temps peut être considéré comme à peu près constant, il s'agit d'un temps de commutation de contexte très peu dépendant du processus à réactiver (la seule dépendance, liée à la présence ou non du code à réactiver dans le cache, n'est pas maitrisable). Sur ce point on peut donc trouver un temps majorant assez simplement.
L'interruption d'un processus utilisateur est de la même veine. Dans le cas particulier, donc, d'un processus utilisateur à interrompre, la qualité temps réel de la réquisition du processeur par le système pau profit d'un autre processus est complètement liée à la qualité temps réel de la sélection du processus à sélectionner (le scheduler).
Cas un peu plus complexe mais très fréquent : la sollicitation arrive sous forme d'une interruption. En rajoutant l'hypothèse que le processus en cours est un processus utilisateur. C'est un cas qui peut se ramener rapidement au précédent, puisque la commutation de tâches dans un système à temps partagé se fait en programmant un générateur d'interruptions (timer). On a donc "simplement" rajouté le temps de traitement particulier de l'interruption considérée - et ôté la durée du handler du timer.
Les *vrais cas difficiles c'est quand on interrompt un bout de code kernel.
Du point de vue d'une application, le temps est continu, la seule chose à prendre en compte est que le temps entre deux "gettimeofday" est foncièrement indécidable. L'important donc pour un code en mode utilisateur, c'est essentiellement de pouvoir réquisitionner le processeur dans des temps bornés (réaction à sollicitation), ou en temps prévu (interval timer).
Or cette réquisition va se faire moyennant un certain délai, entièrement du ressort de l'OS : le temps d'interrompre une tâche (user ou kernel) en cours, le temps de sélectionner la tâche à éxécuter, le temps de reprendre.
Concernant la reprise, le temps peut être considéré comme à peu près constant, il s'agit d'un temps de commutation de contexte très peu dépendant du processus à réactiver (la seule dépendance, liée à la présence ou non du code à réactiver dans le cache, n'est pas maitrisable). Sur ce point on peut donc trouver un temps majorant assez simplement.
L'interruption d'un processus utilisateur est de la même veine. Dans le cas particulier, donc, d'un processus utilisateur à interrompre, la qualité temps réel de la réquisition du processeur par le système pau profit d'un autre processus est complètement liée à la qualité temps réel de la sélection du processus à sélectionner (le scheduler).
Cas un peu plus complexe mais très fréquent : la sollicitation arrive sous forme d'une interruption. En rajoutant l'hypothèse que le processus en cours est un processus utilisateur. C'est un cas qui peut se ramener rapidement au précédent, puisque la commutation de tâches dans un système à temps partagé se fait en programmant un générateur d'interruptions (timer). On a donc "simplement" rajouté le temps de traitement particulier de l'interruption considérée - et ôté la durée du handler du timer.
Les *vrais cas difficiles c'est quand on interrompt un bout de code kernel.
lundi 21 avril 2008
O temps suspends ton vol...
Je viens de voir à l'occasion de la sortie du kernel Linux 2.6.25 l'existence de l'outil latencytop. De quoi au moins outiller mes propos, pour les latences que l'outil saura mesurer.
Après parcours de la liste des innovations de la 2.6.25, il semble que l'effervescence se soit calmée pour la partie scheduler. Tant mieux, il y a tant à dire pour la 2.6.24 !
Les latences possibles que j'imagine au niveau kernel (les freins à une latence faible) ?
- tout d'abord le matériel. Il est illusoire de demander à un ARM2 à 8MHz d'obtenir une latence identique à un Core2 duo dont la fréquence interne est facilement 250 fois supérieure ! De même les accès RAM et les débits RAM ont profité d'une amélioration spectaculaire ces 10 dernières années et les systèmes auxquels on demande les meilleures perfs RT ne sont pas les machines dernier cri...
- ensuite le codage interne du kernel. Blocage sous Mutex, Ordonnaceur trop long, interruptions désactivées trop longtemps sont les principales causes d'accroissement de latence. Un handler d'IT mal écrit peut décider de la latence complète du système. Ce n'est pas propre à Linux, un vendeur d'OS temps réel l'a appris à ses dépends sur son propre driver disque dur !
- Enfin l'utilisation du système. une machine qui croule régulièrement sous la charge, dimensionnée pour accepter juste la charge, ne sera peut-être pas en mesure de tenir systématiquement uen latence faible. On ne peut exiger d'une machine prévue pour bosser 10 secondes à 110% de ses capacités de prétendre avoir un comportement temps réel pendant cette surcharge sans risquer de voir certaines piles déborder (au mieux), certaines latences diverger (au pire).
Donc on commencera à parler de temps réel sous les conditions suivantes :
- Les erreurs de codage manifestes sont exclues,
- L'erreur de sous-dimensionnement pour de longs intervalles est écartée,
- On demande au matériel des latences qu'il a une chance de tenir.
Après parcours de la liste des innovations de la 2.6.25, il semble que l'effervescence se soit calmée pour la partie scheduler. Tant mieux, il y a tant à dire pour la 2.6.24 !
Les latences possibles que j'imagine au niveau kernel (les freins à une latence faible) ?
- tout d'abord le matériel. Il est illusoire de demander à un ARM2 à 8MHz d'obtenir une latence identique à un Core2 duo dont la fréquence interne est facilement 250 fois supérieure ! De même les accès RAM et les débits RAM ont profité d'une amélioration spectaculaire ces 10 dernières années et les systèmes auxquels on demande les meilleures perfs RT ne sont pas les machines dernier cri...
- ensuite le codage interne du kernel. Blocage sous Mutex, Ordonnaceur trop long, interruptions désactivées trop longtemps sont les principales causes d'accroissement de latence. Un handler d'IT mal écrit peut décider de la latence complète du système. Ce n'est pas propre à Linux, un vendeur d'OS temps réel l'a appris à ses dépends sur son propre driver disque dur !
- Enfin l'utilisation du système. une machine qui croule régulièrement sous la charge, dimensionnée pour accepter juste la charge, ne sera peut-être pas en mesure de tenir systématiquement uen latence faible. On ne peut exiger d'une machine prévue pour bosser 10 secondes à 110% de ses capacités de prétendre avoir un comportement temps réel pendant cette surcharge sans risquer de voir certaines piles déborder (au mieux), certaines latences diverger (au pire).
Donc on commencera à parler de temps réel sous les conditions suivantes :
- Les erreurs de codage manifestes sont exclues,
- L'erreur de sous-dimensionnement pour de longs intervalles est écartée,
- On demande au matériel des latences qu'il a une chance de tenir.
Inscription à :
Messages (Atom)