Estou interessado em limites teóricos, talvez com exemplos de sistemas com um grande número de CPUs.
Pelo menos 2048 na prática. Como um exemplo concreto, a SGI vende seu sistema UV , que pode usar 256 soquetes (2.048 núcleos) e 16 TB de memória compartilhada, tudo rodando sob um único kernel. Eu sei que existem pelo menos alguns sistemas que foram vendidos nesta configuração.
De acordo com a SGI:
Altix UV runs completely unmodified Linux, including standard distributions from both Novell and Red Hat.
isso é o que o tem que dizer sobre o Ubuntu, então eu acho que se aplica a outros:
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.
São 32 ou 64 CPUs para x86 e x86_64, respectivamente.
Redhat diz o mesmo, mas em uma tabela amiga da gerência . O Redhat EL6 pode fazer 32 para x86, ou 128 ou 4096 núcleos de CPUs para x86_64.
O kernel Linux x86_64 pode lidar com um máximo de 4096 threads de processador em uma única imagem do sistema. Isso significa que, com o hyper-threading ativado, o número máximo de núcleos do processador é 2048. Sim, há computadores com mais de 2048 núcleos de processador; mas estes são executados como clusters onde vários kernels Linux cooperam, conectados a uma interconexão de alta velocidade, tipicamente um tecido Infiniband.
do kernel 3.13 mais atual, em ~ / 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.
Atualização: Nos kernels mais recentes, isso é específico da arquitetura - por exemplo, em 4.15 x86_64 permite que você defina NR_CPUS como 8192 nas circunstâncias corretas, enquanto 32 bits braço pára em 32 .
Este bebê é executado 10,368!
Threads são subjetivos ao modelo multitarefa e ao esquema de gerenciamento de threads. O Gdt dos sistemas baseados em intel é usado no Linux, se bem me lembro. A idéia é que tem uma possibilidade 8192 threads no tamanho máximo. Isso assumindo que o sistema está usando o gdt para gerenciar os encadeamentos. Em máquinas de 32 bits, a comutação de tarefas é gerenciada e as máquinas de interrupção de vetores de 32 e 64 bits precisam ter entradas gdt. Não tenho certeza de como o braço faz isso, mas a mesma articulação deve ser alcançada. Os conceitos de comutação de tarefas iteram o GDT em modelos de tarefas.
Se você sair do esquema de gdt, você pode alcançar o que você tem memória para quando você tem, para cada thread, um quadro de pilha de página, base de código de página para o segmento e página de espaço de heap. Você não pode supor que você tenha uma página de código ou heap, que são as variáveis aleatórias. Geralmente, há dois quadros de pilha para cada encadeamento, um mantido pelo encadeamento e outro mantido pelo kernel do Linux. Você adiciona conceitos de memória virtual de espaço de troca e o modelo é soprado para fora da água, mas é sobre prioridade de thread.