S'il y a deux processeurs dans un système, le deuxième processeur peut-il être contrôlé s'il a une architecture différente?

Question

Dites que j'avais un ordinateur qui avait 2 processeurs, l'un utilisé x64, et l'autre utilisé ARM. Un noyau Linux x64 pourrait-il contrôler le second processeur (ARM)?

Answer 1

Je pense (avec une grande quantité de travail de génie logiciel, mais pas d'obstacles insurmontables que je peux voir), vous pouvez exécuter un seul noyau Linux ARM + x86 sur une machine hypothétique cache cohérente avec un mélange de noyaux ARM + x86 , par exemple.

Celles-ci n'existent pas; plusieurs processeurs d'architectures différentes dans le même système effectuent toujours des tâches différentes et sont connectés à différentes RAM, et communiquent sur certains bus, comme SATA ou PCIe. Je réponds à cet aspect de la question parce que c'est le seul qui soit intéressant/non trivial.

Il y aurait un pool partagé de mémoire partagée par l'ensemble du système, donc la mémoire serait essentiellement partagée de manière compétitive entre les processus ARM et x86, au lieu de devoir la partitionner de manière statique. Le pagecache (également appelé cache de disque) serait également partagé, ainsi que d'autres caches (comme les entrées/inodes du répertoire VFS).

La plupart des interactions intra-CPU dans le noyau viennent d'être effectuées en écrivant en mémoire et en attendant que le code noyau d'un autre noyau le remarque. (par exemple, si un processus démarre un nouveau thread et continue à fonctionner, le noyau place cette nouvelle tâche dans la liste des tâches où un autre core qui exécute le planificateur le remarquera. core pour que le thread s'exécute, les cœurs regardent plutôt la liste des tâches et choisissent quelque chose à faire.)

Aussi longtemps que la mémoire partagée cohérente en cache fonctionne correctement et que les processus x86 et ARM peuvent se synchroniser les uns avec les autres avec des barrières de mémoire et ainsi de suite, je ne vois pas pourquoi cela ne serait pas possible en théorie. Les pilotes doivent déjà travailler sur les systèmes SMP, aussi longtemps que le verrouillage fonctionne correctement pour exclure d'autres threads (qu'ils soient ARM ou x86), les choses devraient fonctionner.

Vous auriez besoin:

• pointeurs de fonction dans le noyau. Chaque pointeur de fonction du noyau doit avoir une version x86 et une version ARM. Linux fait un usage intensif des pointeurs de fonction pour les envoyer au bon pilote, par ex. un système de fichiers. Merde, je viens de penser à celui-ci après avoir écrit la plupart du reste de la réponse, et il peut être un coup de projecteur. Je pourrais imaginer utiliser un compilateur C++ pour compiler le noyau, ainsi vous pourriez remplacer les pointeurs de fonction dans chaque struct par un wrapper de template qui avait de la place pour deux pointeurs, et dereferencing prendre le bon pointeur pour l'architecture. Mais prendre l'adresse d'une fonction pour stocker un pointeur de fonction dans une structure signifie que le code ARM doit savoir quel est le bon pointeur x86 à affecter, et vice-versa.

  Ou peut-être si vous êtes fou, vous pouvez configurer le mappage de la mémoire et la mise en page binaire, donc cœurs x86 voir la version x86 d'une fonction à la même adresse virtuelle ARM noyaux voir la version ARM de cette fonction. Vous n'avez besoin de cela que pour les fonctions dont les adresses sont prises, mais cela semble fou et il faudrait beaucoup de fiddling pour que l'éditeur de liens laisse assez de marge pour que cela soit possible étant donné que différentes architectures auront des tailles de code machine différentes la même fonction.

  Avec un noyau moins flexible qui n'a pas mis autant de pointeurs de fonctions dans les structures ops pour différents systèmes de fichiers, ce serait plus facile.

  Peut-être que vous pourriez avoir des versions ARM et x86 de chaque struct ops, et les auteurs devraient fixer les deux, mais les lecteurs ne ferait que lire celui qu'ils veulent. Ils ne sont pas réglés fréquemment, surtout quand un nouveau FS est monté, ou un nouveau périphérique branché, je pense. Toutes les mises en page de structure doivent être compatibles (peut-être une tonne de travail, ou peut-être simplement obtenir de l'aide du compilateur en modifiant l'ABI).

• Le planificateur a besoin de savoir qu'il ne doit exécuter des processus ARM sur des cœurs ARM et x86 processus sur des noyaux x86.

• Le système doit être en mesure de démarrer en quelque sorte, et obtenir deux images noyau construit à partir de la même source chargée en mémoire. Cela va être le défi majeur, car il y a probablement des hypothèses sur les adresses physiques/virtuelles dans lesquelles vit le noyau. Le processus de démarrage doit charger deux copies du code du noyau, mais seulement une copie des données en lecture seule et des données statiques. -constantes données. (Et les deux morceaux de code doivent avoir les bonnes adresses pour toutes ces choses).

• Gestion de la mémoire: ARM et x86 utilisent différents formats de table de page. Un processus x86 lisant le /proc/<pid>/maps d'un processus ARM provoquera probablement le noyau à regarder les tables de pages pour un processus de l'autre architecture. (Ou peut-être Linux conserve-t-il cette information dans un format de début/longueur de mappage ainsi que dans les tables de pages réelles.) Cependant, je pourrais imaginer que cela soit un problème. Le noyau gérant le pool de mémoire à l'échelle du système peut également être difficile, s'il y a des suppositions sur l'emplacement du code du noyau qui sont violées en chargeant deux versions différentes. Threads: Si vous souhaitez utiliser tous les cœurs ARM x86 + dans le système pour une tâche de mémoire partagée, vous devez le faire avec deux processus qui mappent de la mémoire partagée. L'alternative est d'écrire un nouvel appel système qui permet à un processus x86 de démarrer un thread ARM, de la même façon que le noyau fonctionne, mais ce est où cela prendrait probablement beaucoup de travail. C'est certainement là où le problème des formats de page-table-séparés va mordre, car tous les threads d'un processus partagent normalement la même table de pages.

• Les macros de barrière de mémoire, etc., doivent être implémentées d'une manière qui se synchronise avec le code exécuté sur les cœurs de l'autre architecture. On peut supposer que les cœurs x86 seraient toujours obéir au modèle de mémoire x86, où les magasins deviennent visibles globalement dans l'ordre du programme, etc., etc. (Voir le wiki tag x86 pour des liens plus sur le modèle de mémoire x86). De même, les noyaux ARM obéiraient au modèle de mémoire ARM habituel, de sorte que leurs charges pourraient devenir globalement visibles dans le désordre, si elles n'utilisent pas de barrières ou n'acceptent pas de charges, que le cœur qui a produit les données soit ARM ou x86.

  Memory-commande est tout au sujet de l'ordre de son cache L1 privé propres opérations d'un noyau (ce qui est cohérent avec toutes les autres caches de données dans le système). Les tampons de magasin permettent une réorganisation invisible, mais une fois que quelque chose est écrit dans le cache L1, il est visible partout, peu importe qui le lit. C'est ce que cela signifie pour que les caches soient cohérentes. Donc, la question est de savoir si les idiomes de synchronisation dépendent d'hypothèses sur l'autre thread, ce qui peut ne pas être vrai s'il utilise un modèle de mémoire différent. par exemple. un verrou pris par un noyau ARM doit exclure les threads x86 de la section critique, et vice-versa. Je pense que cela devrait surtout marcher, mais c'est le seul domaine auquel j'ai pensé jusqu'ici, dont je ne suis pas sûr.Cela pourrait nécessiter des réglages pour certaines macros Linux inline-asm. Linux résumés beaucoup de cela pour une utilisation par des parties indépendantes arc du noyau, il est donc assez bien mis en place pour faire (barrière de mémoire d'écriture) smp_wmb() plus forte si nécessaire, par exemple.