Сколько ядер может обрабатывать ядро ​​Linux?

Меня интересуют теоретические ограничения, возможно, примеры систем с огромным количеством процессоров.

По крайней мере, 2048 на практике. В качестве конкретного примера, SGI продает свою ультрафиолетовую систему, которая может использовать 256 сокетов (2048 ядер) и 16 ТБ общей памяти, и все они работают под одним ядром. Я знаю, что в этой конфигурации было продано как минимум несколько систем.

По данным SGI:

Altix UV работает на полностью неизмененном Linux, включая стандартные дистрибутивы от Novell и Red Hat.

Вот что Launchpad говорит об Ubuntu, так что, думаю, это относится и к другим:

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.

Это 32 или 64 процессора для x86 и x86_64 соответственно.

Redhat говорит то же самое, но в удобной для управления таблице . Redhat EL6 может сделать 32 для x86, или 128 или 4096 ядер для x86_64.

Ядро Linux x86_64 может обрабатывать максимум 4096 потоков процессора в одном образе системы. Это означает, что при включенной гиперпоточности максимальное количество ядер процессора составляет 2048. Да, есть компьютеры с более чем 2048 ядрами процессора; но они работают как кластеры, в которых взаимодействуют несколько ядер Linux, связанных высокоскоростным межсоединением, как правило, фабрикой Infiniband.

из самого последнего ядра 3.13, в ~ / 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.

Обновление: на более новых ядрах это зависит от архитектуры - например, в 4.15 x86_64 позволяет вам установить NR_CPUS на 8192 при правильных обстоятельствах, тогда как 32-битное плечо останавливается на 32 .

Этот ребенок бежит 10,368!

Потоки субъективны модели многозадачности и схеме управления потоками. Gdt систем на базе Intel используется в Linux, если я правильно помню. Идея состоит в том, чтобы иметь возможность 8192 потоков в максимальном размере. Это при условии, что система использует gdt для управления потоками. На 32-битных машинах переключение задач управляется, и на 32- и 64-битных машинах векторы прерываний должны иметь записи gdt. Не уверен, как рука делает это, но та же артикуляция должна быть достигнута. Концепции переключения задач повторяют GDT в моделях задач.

Если вы выйдете из схемы gdt, вы, вероятно, сможете достичь того, на что у вас есть память, когда у вас есть для каждого потока кадр стека страниц, база кода страницы для потока и страница пространства кучи. Вы не можете предполагать, что у вас есть страница кода или кучи, которая является случайными переменными. Обычно есть два стековых фрейма для каждого потока, один поддерживается потоком, а другой поддерживается ядром linux. Вы добавляете понятия виртуальной памяти в пространство подкачки, и модель вырывается из воды, но она имеет приоритет потока.

Также:

Если вы используете Linux в качестве Контроллера на UV SGI, и вы используете Bladecenters вместе с ней на собственном Ядре 4.15, вы можете использовать на Моменте:

4096 Стойки с клинками. 1 стойка с использованием 1024 ядер x 4096 ядер. Эта Конфигурация будет на данный момент самой мощной версией ядра под Linux. Вы можете контролировать все ядра в Red Hat.