Appel de fonctions versus appels de methode virtuelles, la deuxieme necessite une indirection de plus comme dit precedemment, ce qui se traduit par un saut indirect via une table d'adresse.Citation:
Envoyé par coda_blank
Version imprimable
Appel de fonctions versus appels de methode virtuelles, la deuxieme necessite une indirection de plus comme dit precedemment, ce qui se traduit par un saut indirect via une table d'adresse.Citation:
Envoyé par coda_blank
Je pense que non car tu es alors soumis au scheduler de l'OS hôte, que la machine virtuelle ne peut pas voir...Citation:
Envoyé par Lightness1024
hmm, parce que les timers haute precision mesure le total real time et pas le total cpu time c'est ca ? comment ça marche d'ailleurs c'est un registre special dans le CPU ?
Ca peut marcher de plein de manière différentes - basé sur des IT ou non (CONFIG_NO_HZ, si je ne me trompe pas), en comptant les cycles cpu, etc.Citation:
Envoyé par Lightness1024
Ce n'est toutefois pas un problème de timer. Lorsqu'on fait tourner un kernel RT dans une machine virtuelle, ce kernel est dépendant de l'architecture sous-jacente. Si le processeur accepte la virtualisation hardware, il lui faut quand même du temps (non contrôlé par l'OS gues, mais par l'OS host) pour passer dans le mode Ring-0 émulé. Dans le cas où la virtualisation hardware n'est pas implémentée, inutile d'aller plus loin : les instructions kernel qui doivent s'exécuter en Ring-0 sont émulées (et là, la notion de performance ne veut plus rien dire).
Au delà de ça, le RT ne peut s'atteindre que si tous les composants de la chaine sont au courant qu'on fait tu temps réel. Problème : l'OS hôte ne sait pas que l'OS guest est un OS RT, donc le logiciel de virtualisation est soumis aux contraintes classiques d'un programme userspace normal (et s'exécute sur un scheduler normal). Dans ces conditions, en comprennant bien que l'OS client RT peut être intérrompu à tout moment par l'OS hote non RT, et que c'est l'OS hote non RT qui rend la main à l'OS client quand il le souhaite, on conçoit facilement qu'aucune contrainte temps réel ne peut être tenue par l'OS virtualisé.
Ceci dit, si tu es sur Debian (je suis sous wheezy/sid), tu as un package kernel PREEMPTRT (3.0.0-1-rt) que tu peux installer en lieu et place de ton kernel courant. Si tu es sur une autre distro, je ne sais pas si c'est possible.
je vois je vois, et je m'en doutais bien.
mais j'aurais cru que selon ce que voyais le timer, ca pouvait marcher quand meme:
en effet si on imagine que lorsque l'OS client est déschédulé, le timer ne voit pas le trou temporel jusqu'au prochain scheduling, ca pourrait tres bien faire l'affiare, voyez vous ?
donc c'est pour ca que je focalise sur ce "timer" et que je trouve que c'est effectivement un problème de timer. si le timer lisait une valeur qui se "freeze" lorsque l'OS client est deschedulé, ca marcherait quelque soit le kernel hôte.
non ?
Dans ce cas là, l'OS guest ne pourrait jamais être à l'heure :)Citation:
Envoyé par Lightness1024
oui absolument. et les applis temps réel tournerait un peu ralenties, ou lagguées. mais ca pourrait etre une option de la machine virtuelle.
Quel intérêt ? Une appli TR ne joue jamais toute seule : elle dialogue avec quelque chose (matériel, serveur distant, n'importe quoi en fait ; certains protocoles de communication nécessite des temps de réponse maximum définis (je pense au protocole qui permet de gérer les FAX, par exemple)), et c'est ce quelque chose qui a besoin d'avoir des temps de réponse définis et sûr. A moins d'émuler la fonctionnalité traitée, ce qui multiplie le travail, ce n'est pas viable.Citation:
Envoyé par Lightness1024
ok. donc conclusion des courses, kernel RT = natif :cry:. fin du semi hors sujet :?