Quali sono gli effetti, se ve ne sono, delle priorità e delle politiche dello scheduler per i thread in un cpuset non conteso?

Ho un sistema Linux in cui abbiamo usato cgroups per creare due cpuset esclusivi cpu, A e B, e dove abbiamo migrato tutti i thread utente e tutti i thread kernel non associati a un cgroup collegato a cpuset A. Le cose in esecuzione in cpuset A hanno politiche di pianificazione variabili e priorità variabili, e ci sono molti più thread in esecuzione in cpuset A rispetto a core in cpuset A.

Esiste anche un piccolo numero di processi molto attivi collegati a cpuset B, in cui il numero totale di thread utente attraverso questi processi non è mai superiore al numero di core disponibili esclusivamente in cpuset B. L'obiettivo è proteggere questi importanti compiti in esecuzione in cpuset B da altre attività sulla macchina e per ridurre al minimo la latenza di elaborazione.

In tale configurazione, la politica / priorità di pianificazione dei thread utente in esecuzione in cpuset B ha qualche effetto osservabile? Detto diversamente: la modifica della politica di pianificazione dei thread B cpuset da SCHED_OTHER predefinito a SCHED_FIFO o SCHED_RR avrebbe conseguenze, buone o cattive?

Sembra che la risposta dovrebbe essere "no", dal momento che lo scheduler dovrebbe essere in grado di assegnare a ogni thread in esecuzione in cpuset B il proprio core dedicato, quindi non ci sarebbe nulla da stabilire le priorità o la pianificazione, quindi la politica e la relativa priorità della B i thread di cpuset non contano. D'altra parte, ci sono i thread del kernel associati e gli aspetti del "dominio dello scheduler" di cui preoccuparsi, e probabilmente altre cose che non ho considerato.

Le politiche di pianificazione e le priorità dei thread in esecuzione in un cpuset esclusivo sottoposto a overprovisioning sono in qualche senso pratico?

La fascia oraria utilizzata è importante per i lavori a uso intensivo di CPU che richiedono la persistenza della cache, a meno che non si blocchi un core specifico per ciascun PID. È possibile aumentare la fascia oraria con il criterio di pianificazione SCHED_BATCH e migliorare le prestazioni fino al 300% in alcuni casi, riducendo al contempo la reattività interattiva. L'effetto opposto di intervalli di tempo più piccoli si verifica con SCHED_RR (che ridurrà il throughput ma aumenterà la reattività in tempo reale).

È possibile utilizzare schedtool per impostare la politica di PID specifici per tutti i PID nell'insieme B come singolo comando. Può anche essere utilizzato per bloccare specifici PID su specifici core, che sarebbe la soluzione ottimale poiché la persistenza della cache non dipende più dalla fascia oraria, ma ciò richiede uno sforzo maggiore poiché è necessario eseguire un comando schedtool separato per ciascun PID.

Se ogni processo ha il suo core, allora non ci sono vincoli di priorità.

Tuttavia, se pianifichi un processo che richiede 30 minuti per essere eseguito ogni 15 minuti, inizierai ad avere la necessità di stabilire delle priorità poiché il processo inizierà a sovrapporsi.

Non esiste tuttavia una "migliore" politica di pianificazione.

Dipendono davvero da ciò che vuoi ottenere. Ma all'inizio, lo lascerei a SCHED_OTHER, il valore predefinito e lo osserverei per qualche tempo prima di provare cose più specializzate.