Сколько это может выдержать? или сколько он может обработать, прежде чем потерять какую-то выгоду? и какое ядро? Я подозреваю, что этот ответ несколько меняется для компьютера, на котором установлен патч для запуска суперкомпьютера. Кажется, я вспомнил, что читал об одном экземпляре с использованием 4096 процессоров ...
xenoterracide
Что за набор патчей, обычный набор патчей не может обрабатывать 4096 процессоров, но для этого был исправлен linux. (IIRC некоторые ответы, кажется, предполагают, что это возможно)
ксенотеррацид
@xeno Я думаю, что тот факт, что есть даже набор патчей для 4096 процессоров, - это то, что следует упомянуть в ответе.
Чепанг
Я не помню больше, чем это, в противном случае я бы дал ответ, я также ее достижения производительности пройти 16? ядра были ограничены ... и что некоторые части ядра нуждались в переписывании, которое уже началось. но на самом деле у меня нет никаких ссылок и я не на 100%, поэтому я не отвечаю.
По крайней мере, 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.
arch / x86 / Kconfig говорит, что эти CONFIG_NR_CPUSограничения могут быть увеличены, если CONFIG_MAXSMPвключено.
2010 года
6
Ядро 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.
Я знаю, что это старый пост, но вы ссылаетесь на кластерный компьютер. Вопрос в том, чтобы запустить один экземпляр ядра.
frodeborli
1
Потоки субъективны модели многозадачности и схеме управления потоками. 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.
Ответы:
По крайней мере, 2048 на практике. В качестве конкретного примера, SGI продает свою ультрафиолетовую систему, которая может использовать 256 сокетов (2048 ядер) и 16 ТБ общей памяти, и все они работают под одним ядром. Я знаю, что в этой конфигурации было продано как минимум несколько систем.
По данным SGI:
источник
Вот что Launchpad говорит об Ubuntu, так что, думаю, это относится и к другим:
Это 32 или 64 процессора для x86 и x86_64 соответственно.
Redhat говорит то же самое, но в удобной для управления таблице . Redhat EL6 может сделать 32 для x86, или 128 или 4096 ядер для x86_64.
источник
CONFIG_NR_CPUSограничения могут быть увеличены, еслиCONFIG_MAXSMPвключено.Ядро Linux x86_64 может обрабатывать максимум 4096 потоков процессора в одном образе системы. Это означает, что при включенной гиперпоточности максимальное количество ядер процессора составляет 2048. Да, есть компьютеры с более чем 2048 ядрами процессора; но они работают как кластеры, в которых взаимодействуют несколько ядер Linux, связанных высокоскоростным межсоединением, как правило, фабрикой Infiniband.
из самого последнего ядра 3.13, в ~ / arch / x86 / Kconfig:
config NR_CPUS
Обновление: на более новых ядрах это зависит от архитектуры - например, в 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.
источник