{"id":1181,"date":"2025-09-22T12:43:31","date_gmt":"2025-09-22T10:43:31","guid":{"rendered":"https:\/\/elearningsamba.com\/index.php\/le-multikernel-la-prochaine-revolution-linux\/"},"modified":"2025-09-22T12:43:31","modified_gmt":"2025-09-22T10:43:31","slug":"le-multikernel-la-prochaine-revolution-linux","status":"publish","type":"page","link":"https:\/\/elearningsamba.com\/index.php\/le-multikernel-la-prochaine-revolution-linux\/","title":{"rendered":"Le Multikernel – La prochaine r\u00e9volution Linux"},"content":{"rendered":"

H\u00e9 bien figurez-vous qu\u2019un d\u00e9veloppeur nomm\u00e9 Cong Wang de Multikernel Technologies vient de proposer une solution radicale qui consiste \u00e0 donner \u00e0 chaque processus son propre kernel Linux, avec ses propres core CPU, comme des colocataires qui auraient enfin chacun leur studio\u2026<\/p>\n

\nSelon le patch soumis sur la Linux Kernel Mailing List<\/a>
\n(LKML<\/strong>), cette architecture \u201cmultikernel<\/em>\u201d permettrait de faire tourner plusieurs noyaux Linux ind\u00e9pendants sur la m\u00eame machine physique. C\u2019est pas vraiment de la virtualisation classique fa\u00e7on VMware ou KVM, mais c\u2019est plut\u00f4t comme si vous d\u00e9coupiez votre ordinateur en tranches et que chaque tranche vivait sa vie. Le truc marrant, c\u2019est que Cong Wang n\u2019est pas un petit nouveau qui d\u00e9barque avec ses id\u00e9es folles. Le bonhomme a d\u00e9j\u00e0 contribu\u00e9 \u00e0 plus de 1000 patches au noyau Linux et il maintient le sous-syst\u00e8me de
\ntraffic control<\/a>
\n. Autant dire qu\u2019il sait de quoi il parle quand il touche au code du noyau.<\/p>\n

D\u2019ailleurs cette id\u00e9e de s\u00e9parer les kernels rappelle furieusement le projet
\n Barrelfish<\/a>
\nque Microsoft Research et l\u2019ETH Zurich avaient lanc\u00e9 il y a quinze ans. \u00c0 l\u2019\u00e9poque, ils voulaient traiter l\u2019OS comme un syst\u00e8me distribu\u00e9 o\u00f9 chaque core CPU aurait son propre kernel qui communique avec les autres par messages. Sauf que voil\u00e0, c\u2019\u00e9tait trop t\u00f4t. Les processeurs n\u2019avaient pas assez de cores pour qu\u2019on puisse se permettre ce genre de luxe, et puis franchement, qui avait besoin de \u00e7a en 2009 ?<\/p>\n

Aujourd\u2019hui avec nos CPU \u00e0 128 cores et nos probl\u00e8mes de s\u00e9curit\u00e9 qui explosent, l\u2019id\u00e9e prend soudainement tout son sens.<\/p>\n

\n Selon Phoronix<\/a>
\net les patches sur la LKML, l\u2019impl\u00e9mentation de Wang utilise kexec, ce m\u00e9canisme qui permet normalement de red\u00e9marrer directement dans un nouveau noyau sans repasser par un reboot. Sauf qu\u2019ici, au lieu de remplacer le noyau existant, on en charge plusieurs qui vont cohabiter. Chaque kernel se voit attribuer ses propres cores CPU et ils communiquent entre eux via un syst\u00e8me d\u2019interruptions inter-processeurs (IPI) sp\u00e9cialement con\u00e7u pour l\u2019occasion. Et dans les 7 patches propos\u00e9s en RFC, Wang pr\u00e9voit des m\u00e9canismes de surveillance pour g\u00e9rer tous ces petits mondes parall\u00e8les.<\/p>\n

$\"\"$ <\/p>\n

Et pendant que Cong Wang bricolait son multikernel dans son coin, les g\u00e9ants du cloud comme Amazon, Microsoft et Google ont d\u00e9velopp\u00e9 en parall\u00e8le une technologie appel\u00e9e KHO (
\n Kexec HandOver<\/a>
\n) qui permet de pr\u00e9server l\u2019\u00e9tat syst\u00e8me lors du changement de kernel. En gros, ils veulent pouvoir mettre \u00e0 jour le noyau Linux de leurs serveurs sans perdre les VMs qui tournent dessus. Sauf que si le multikernel de Wang fonctionne vraiment, \u00e7a pourrait rendre leur stack de virtualisation compl\u00e8tement obsol\u00e8te.<\/p>\n

Car pourquoi s\u2019emb\u00eater avec des hyperviseurs complexes quand on peut juste donner \u00e0
\n chaque workload<\/a>
\nson propre kernel ?<\/p>\n

Le plus dr\u00f4le dans tout \u00e7a, c\u2019est que Wang admet candidement dans son RFC que pour l\u2019instant, \u00e7a marche \u201cque sur sa machine de dev avec des param\u00e8tres hardcod\u00e9s<\/em>\u201d.<\/p>\n

Maintenant si cette techno d\u00e9colle, on pourrait voir des trucs assez dingues. Genre un kernel temps r\u00e9el qui g\u00e8re les processus critiques pendant qu\u2019un kernel classique s\u2019occupe du reste. Ou alors des kernels sp\u00e9cialis\u00e9s pour diff\u00e9rents types de workloads : un pour le machine learning, un pour les bases de donn\u00e9es, un pour le r\u00e9seau. Vous pourriez m\u00eame imaginer des kernels avec diff\u00e9rents niveaux de s\u00e9curit\u00e9 du genre un kernel ultra-paranoia pour vos donn\u00e9es sensibles et un kernel plus relax pour Netflix. Et le plus beau c\u2019est que si un kernel plante, les autres continuent de tourner tranquillement.<\/p>\n

C\u2019est comme avoir plusieurs syst\u00e8mes de secours int\u00e9gr\u00e9s directement dans la machine.<\/p>\n

Mais attention, on parle quand m\u00eame d\u2019une RFC, et pas encore d\u2019un truc pr\u00eat pour la prod. La communaut\u00e9 des barbus du noyau va probablement passer des mois \u00e0 d\u00e9battre de chaque ligne de code, et c\u2019est tant mieux parce que toucher \u00e0 l\u2019architecture fondamentale de Linux, c\u2019est pas comme patcher un bug dans Firefox. Si \u00e7a merde, c\u2019est potentiellement des millions de serveurs qui partent en vrille.<\/p>\n

Au final, que ce patch soit accept\u00e9 ou pas, \u00e7a montre surtout que Linux continue d\u2019\u00e9voluer de mani\u00e8re radicale pour toujours aller plus loin ! Et si vous l\u2019\u00e9volution de ce projet,
\ntout se passe sur la LKML<\/a>
\n.<\/p>\n

\n Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"