Combien de cœurs le noyau Linux peut-il gérer?

Je m'intéresse aux limites théoriques, peut-être avec des exemples de systèmes ayant un grand nombre de CPU.

Au moins 2048 en pratique. À titre d'exemple concret, SGI vend son système UV , qui peut utiliser 256 sockets (2 048 cœurs) et 16 To de mémoire partagée, tous fonctionnant sous un seul noyau. Je sais qu'il y a au moins quelques systèmes qui ont été vendus dans cette configuration.

Selon SGI:

Altix UV fonctionne sous Linux complètement non modifié, y compris les distributions standard de Novell et de Red Hat.

c'est ce que Launchpad a à dire sur Ubuntu, donc je suppose que cela s'applique aux autres:

1.Intel x86:
Maximum CPUs: 32 (including logical CPUs)
Maximum memory: 64GB
Maximum filesize: 8TB
Maximum filesystem size (ext3) 16TB
Maximum per-process virtual address space: 4GB

2.AMD64/EM64T:
Maximum CPUs: 64
Maximum memory: 128GB
Maximum filesize: 8TB
Maximum filesystem size (ext3): 16TB
Maximum per-process virtual address space: N/A

These are standard max limitations whereas Linux cluster systems can scale up to 1024 CPU's.

Soit 32 ou 64 processeurs pour x86 et x86_64 respectivement.

Redhat dit la même chose, mais dans une table conviviale . Redhat EL6 peut en faire 32 pour x86, ou 128 ou 4096 cœurs de processeur pour x86_64.

Le noyau Linux x86_64 peut gérer un maximum de 4096 threads de processeur dans une seule image système. Cela signifie qu'avec l'hyper threading activé, le nombre maximum de cœurs de processeur est de 2048. Oui, il existe des ordinateurs avec plus de 2048 cœurs de processeur; mais ceux-ci fonctionnent comme des clusters où plusieurs noyaux Linux coopèrent, connectés avec une interconnexion à haute vitesse, généralement une structure Infiniband.

à partir du noyau 3.13 le plus récent, dans ~ / arch / x86 / Kconfig:

config NR_CPUS

    ---help---
      This allows you to specify the maximum number of CPUs which this
      kernel will support.  If CPUMASK_OFFSTACK is enabled, the maximum
      supported value is 4096, otherwise the maximum value is 512.  The
      minimum value which makes sense is 2.

      This is purely to save memory - each supported CPU adds
      approximately eight kilobytes to the kernel image.

Mise à jour: sur les noyaux plus récents, cela est spécifique à l'architecture - par exemple sur 4.15 x86_64 vous permet de définir NR_CPUS sur 8192 dans les bonnes circonstances alors que le bras 32 bits s'arrête à 32 .

Ce bébé court 10,368!

Les threads sont subjectifs au modèle multitâche et au schéma de gestion des threads. Le Gdt des systèmes basés sur Intel est utilisé sous Linux si je me souviens bien. L'idée est qu'il a une possibilité de 8192 fils à la taille maximale. Cela en supposant que le système utilise le gdt pour gérer les threads. Sur les machines 32 bits, la commutation des tâches est gérée et les vecteurs d'interruption sur les machines 32 et 64 bits doivent avoir des entrées gdt. Je ne sais pas comment le bras le fait, mais la même articulation doit être obtenue. Les concepts de changement de tâche itèrent le GDT dans les modèles de tâches.

Si vous sortez du schéma gdt, vous pouvez probablement atteindre ce que vous avez de mémoire lorsque vous avez, pour chaque thread, un cadre de pile de pages, une base de code de page pour le thread et une page d'espace de tas. Vous ne pouvez pas supposer que vous avez une page de code ou de tas, qui sont les variables aléatoires. Généralement, il y a deux cadres de pile pour chaque thread, l'un maintenu par le thread et l'autre maintenu par le noyau linux. Vous ajoutez des concepts de mémoire virtuelle d'espace d'échange et le modèle est soufflé hors de l'eau, mais il s'agit de la priorité des threads.

Aussi:

Si vous utilisez un Linux comme contrôle sur l'UV SGI et que vous utilisez les Bladecenters avec elle sur votre propre noyau 4.15, vous pouvez utiliser sur le Moment:

4096 Racks de lames. 1 rack utilisant 1024 cœurs x 4096 cœurs. Cette configuration sera pour l'instant le Core le plus élevé à utiliser sous Linux. Vous pouvez contrôler tous les cœurs sous Red Hat.