Quanti core può gestire il kernel Linux?

Sono interessato ai limiti teorici, forse con esempi di sistemi con un numero enorme di CPU.

Almeno 2048 in pratica. Ad esempio concreto, SGI vende il suo sistema UV , che può utilizzare 256 socket (2.048 core) e 16 TB di memoria condivisa, il tutto in esecuzione in un singolo kernel. So che ci sono almeno alcuni sistemi che sono stati venduti in questa configurazione.

Secondo SGI:

Altix UV esegue Linux completamente non modificato, comprese le distribuzioni standard di Novell e Red Hat.

questo è ciò che Launchpad ha da dire su Ubuntu, quindi suppongo che si applichi ad altri:

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.

Sono 32 o 64 CPU rispettivamente per x86 e x86_64.

Redhat dice lo stesso, ma in una tabella di gestione . Redhat EL6 può eseguire 32 core x86 o 128 o 4096 CPU per x86_64.

Il kernel Linux x86_64 può gestire un massimo di 4096 thread del processore in una singola immagine di sistema. Ciò significa che con l'hyper threading abilitato, il numero massimo di core del processore è 2048. Sì, ci sono computer con più di 2048 core del processore; ma questi funzionano come cluster in cui cooperano diversi kernel Linux, collegati con un'interconnessione ad alta velocità, in genere un tessuto Infiniband.

dal kernel 3.13 più recente, in ~ / arch / x86 / Kconfig:

configura 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.

Aggiornamento: sui kernel più recenti questo è specifico dell'architettura - ad esempio su 4.15 x86_64 consente di impostare NR_CPUS su 8192 nelle giuste circostanze mentre il braccio a 32 bit si ferma a 32 .

Questo bambino corre 10.368!

I thread sono soggettivi al modello multitasking e allo schema di gestione dei thread. Il Gdt dei sistemi basati su Intel è usato in Linux se ricordo bene. L'idea è che ha una possibilità 8192 thread alla dimensione massima. Ciò presuppone che il sistema stia usando gdt per gestire i thread. Sulle macchine a 32 bit è gestita la commutazione delle attività e i vettori di interruzione sulle macchine a 32 e 64 bit devono avere voci gdt. Non sono sicuro di come faccia il braccio, ma deve essere raggiunta la stessa articolazione. I concetti di cambio di attività ripetono il GDT nei modelli di tasking.

Se si esce dallo schema gdt, si può presumibilmente raggiungere ciò che si ha memoria quando si dispone, per ogni thread, un frame di stack di pagine, base di codice di pagina per il thread e la pagina dello spazio heap. Non puoi presumere di avere una pagina di codice o heap, ovvero le variabili casuali. Generalmente ci sono due frame stack per ogni thread, uno gestito dal thread e uno gestito dal kernel Linux. Aggiungete concetti di memoria virtuale dello spazio di swap e il modello viene espulso dall'acqua ma si tratta della priorità del thread.

Anche:

Se stai usando un Linux come controllo sul SGI UV e stai usando i Bladecenter con lei sul proprio kernel 4.15, puoi usare sul momento:

4096 Rack per lame. 1 Rack con 1024 Core x 4096 Core. Questa configurazione sarà nel momento il Core più alto che usa sotto Linux. Puoi controllare tutti i core con Red Hat.