ARM big.LITTLE è un’architettura di elaborazione eterogenea sviluppata da ARM Holdings per l’ottimizzazione delle prestazioni, che unisce i core del processore relativamente più economici e più lenti (LITTLE) a quelli relativamente più potenti e assetati di energia (big). In genere, sarà attiva una sola “sezione” di elaborazione alla volta, ma tutti i core hanno accesso alle stesse aree di memoria, quindi i carichi di lavoro possono essere scambiati tra i core Big e Little al volo. L’intenzione è quella di creare un processore multi-core in grado di adattarsi meglio alle esigenze di elaborazione dinamica e utilizzare meno energia rispetto al solo ridimensionamento del clock. Il materiale di marketing di ARM promette un risparmio fino al 75% nel consumo di energia per alcune attività. Più comunemente, le architetture ARM big.LITTLE vengono utilizzate per l’ottimizzazione di un sistema su chip multi-processore (MPSoC).

Le specifiche dell’architettura sono state annunciate nell’ottobre 2011, insieme al processore Cortex-A7, progettato per essere architettonicamente compatibile con Cortex-A15. Nell’ottobre 2012 ARM ha annunciato i core Cortex-A53 (il cuore del Raspberry Pi 3) e Cortex-A57 (ARMv8-A), che sono anche intercompatibili per consentirne l’uso e l’ottimizzazione in un chip big.LITTLE.

I benefici dell’architettura big.LITTLE

Per una determinata libreria di logica CMOS, la potenza attiva aumenta quando la logica commuta più volte al secondo, mentre l’aumento del numero di transistor comporta in genere una perdita di efficienza. Pertanto, le CPU progettate per la velocità hanno un’architettura differente rispetto a quelle progettate per il risparmio energetico. Ad esempio, una CPU veloce che esegua istruzioni fuori sequenza a bassa velocità, magari a causa dell’I/O più lento, risulta penalizzata rispetto ad una CPU con meno transistor che esegua le medesime istruzioni. La CPU più lenta potrebbe ad esempio utilizzare una cache di memoria più piccola (meno transistor) o una microarchitettura più semplice come una pipeline.

L’architettura big.LITTLE è un modo per ottimizzare le risorse in entrambi i casi, garantendo un questo modo potenza e velocità nello stesso sistema.

Nella pratica, un sistema big.LITTLE potrebbe dimostrarsi sorprendentemente poco flessibile. Uno dei classici problemi inerenti a questo tipo di design è il numero e i tipi di domini di alimentazione e di clock forniti dal circuito integrato. Questi domini potrebbero non corrispondere alle funzionalità standard di gestione dell’alimentazione offerte da un sistema operativo. Un altro problema è rappresentato  dal fatto che  le CPU non hanno più capacità equivalenti: diventa pertanto più difficile abbinare il giusto compito software alla giusta CPU.

Fortunatamente, la maggior parte di questi  problemi viene risolta aumentando la flessibilità della circuitazione elettronica e del software.

Caratteristiche architetturali

Esistono tre diverse modalità per disporre cores di processori differenti in modo da sfruttare un design ARM big.LITTLE per l’ottimizzazione, e dipendono tutte dal tipo di scheduler implementato nel kernel.

Clustered switching

Il modello clustered rappresenta l’approccio più semplice da implementare. I processori vengono disposti in cluster di cores “big” o “LITTLE” della medesima grandezza. Lo schedulatore del ssistema operativo vede un solo cluster alla volta: quando il carico sul processore cambia, ad esempio da basso ad alto, il sistema lo sposta sul cluster più potente. Ovviamente tutti i dati utilizzati al momento dello switch passano attraverso la cache L2 comune, il cluster attivbo viene disattivato e l’altro ne prende il posto. Viene usato un sistema definito Cache Coherent Interconnect (CCI). Una modalità simile è stata implementata sul Samsung Exynos 5 Octa (5410).

In-kernel switcher

La migrazione nell’uso della CPU relativo al sistema denominato in-kernel switcher (IKS) è caratterizzato dall’accoppiamento di un core ‘big’ con un core ‘LITTLE’ core, consentendo quindi potenzialmente accoppiamenti multipli in ciascun chip. Ciascuna coppia opera come se fosse un unico cosiddetto virtual core, mentre un solo core reale alla volta risulta (completamente) attivo. Il core ‘big’ viene utilizzato quando le richieste di calcolo sono elevate, mentre viceversa il core ‘LITTLE’ trova impoego quando le richieste sono relative a risorse meno pesanti. Nel momento in cui la richiesta sul virtual core passa da elevata a bassa, il core successivo viene attivato e lo stato di attività viene trasferito, mentre il core precedente viene disattivato. Lo spostamento viene eseguito attraverso il framework cpufreq. Una implementazione completa dell’architettura big.LITTLE IKS è stata realizzata su Linux 3.11, e rappresenta un miglioramento del sistema di cluster migration visto in precedenza, dal momento che in questo caso ciascuna coppia di processori è visibile e quindi accessibile dallo scheduler.

Esiste la possibilità di complicare ulteriormente questa scelta progettuale, raggruppando cores ‘big’ e ‘LITTLE’ in modo non simmetrico. In tal caso, un singolo chip potrebbe avere uno o due cores ‘big’ ma molti più cores ‘LITTLE’, o viceversa. Nvidia ha creato qualcosa di architeturalmente similecon il proprio ‘companion core’ qa basso consumo del Tegra 3 System-on-Chip.

Heterogeneous multi-processing (Global task scheduling)

Abbiamo infine un’incarnazione del modello big.LITTLE detto Multi-Processing Eterogeneo (HMP), che consente l’indirizzamento di tutti i cores fisici presenti contemporaneamente. i thread a maggior priorità o con richieste computazionali maggiori potranno in questo contesto venire allocati sui cores “big” mentre i thread con minore priorità o richieste di calcolo, come i task eseguiti in background, verranno eseguiti dai cores “LITTLE”.

Questo modello è stato implementato su Samsung Exynos a partire dalla serie Exynos 5 Octa (5420, 5422, 5430), e dai processori  Apple mobile application a partire da Apple A11.

Schedulazione

La disposizione accoppiata consente al sistema operativo di passare in modo trasparente da uno stato all’altro, utilizzando la funzione di ridimensionamento dinamico di tensione e frequenza (DVFS) esistente. Il supporto DVFS presente nel kernel vedrà semplicemente un elenco di frequenze / tensioni e passerà da una all’altra come meglio crede, proprio come si comporterebbe sull’hardware esistente. Tuttavia, gli slot di fascia bassa attiveranno il core “Little” e gli slot di fascia alta attiveranno il core “Big”.

In alternativa, tutti i core possono essere esposti allo scheduler del kernel, che deciderà dove eseguire ciascun processo / thread. Tale scelta risulterà obbligata nel caso di esecuzione non accoppiata, ma potrebbe essere utilizzato anche sui sistemi accoppiati. Questa scelta, pur garantendo una maggiore capacità di modulare le risorse, pone seri problemi allo scheduler del kernel, che, almeno con l’hardware attuale, tende ad assumere che tutti i core in un sistema SMP siano uguali anziché eterogenei.

I vantaggi dell’implementazione secondo global task scheduling

• Maggior capacità di modulare il carico da migrare tra i cores. Dal momento che è lo scheduler ad occuparsi in prima persona della migrazione dei task tra i cores, l’overhead del kernel risulta ridotto, garantendo un ulteriorer risparmio di energia.
• L’implementazione nello scheduler rende inoltre ancor più rapida l’attività di switching, rispetto al framework cpufreq implementato nel sistema  IKS.
• Il sistema garantisce il supporto di cluster non simmetrici (ad esempio con 2 cores Cortex-A15 e 4 cores Cortex-A7).
• Viewne reso infine possibile operare simultaneamente su tutti i cores offrendo in tal modo una performance di picco migliore del SoC rispetto al sistema IKS.