Come modificare la frequenza di cambio di contesto Linux?

Come è possibile cambiare la frequenza di cambio di contesto Linux (linaro, ubuntu, debian)?

Sto bene per scambiare un sistema meno reattivo per uno più efficiente.

EDIT1: ho un processo principale che voglio eseguire il più velocemente possibile (cicli di clock massimi al secondo), quindi ho pensato di ridurre la frequenza di cambio di contesto (= aumentare il timeslice). La domanda è come farlo e ci sarebbe un effetto significativo. Posso calcolare il costo del cambio di contesto? Vale a dire, posso stimare se aumento la fascia oraria di due, quale sarà il mio guadagno in termini di prestazioni per il processo principale a cui tengo?

Se la tua attività è l' unico processo che richiede tempo su una CPU specifica, non ci saranno cambi di contesto tra le attività :-). Ma la CPU può ancora essere interrotta, causando un cambio di contesto nel kernel e viceversa. E una possibile causa è il timer di prelazione, che controlla se c'è un'altra attività da eseguire su questa CPU ...

Linux può evitare di generare qualsiasi interruzione del timer di prelazione sulla CPU quando non ci sarà motivo di farlo. Vedere CONFIG_NO_HZ_FULL. Per usare questa funzione, deve essere abilitato quando il kernel è stato creato e deve essere abilitato usando un'opzione di avvio.

• https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
• https://lwn.net/Articles/549580/ "Operazione senza tick (quasi) completa in 3.10"

Per impostazione predefinita, nessuna CPU sarà una CPU con tick adattativi. Il parametro di avvio "nohz_full =" specifica le CPU con tick adattivi. Ad esempio, "nohz_full = 1,6-8" afferma che le CPU 1, 6, 7 e 8 devono essere CPU con tick adattativi. Si noti che è vietato contrassegnare tutte le CPU come CPU a tick adattivo [...]

LWN.net dice "secondo Ingo Molnar, si risparmierà fino all'1% del tempo della CPU" per le CPU con tick adattativi. Il documento del kernel dice che questo ha sei costi diversi, e c'è anche un elenco di "PROBLEMI CONOSCIUTI".

Questo guadagno è relativamente piccolo, in particolare rispetto ai potenziali guadagni di throughput della riduzione della frequenza dei cambi di contesto tra più attività, come indicato in questa risposta: Come modificare la lunghezza delle fasce orarie utilizzate dallo scheduler della CPU Linux?

Piccola stampa: queste misure pre-datano Spectre, Meltdown, KPTI e supporto x86 ASID :-(. E suppongo che si applichino anche a hardware un po 'più vecchio. Chiedi a un esperto del kernel o esegui le tue misurazioni su come ha il costo dei switch di contesto modificato sulla versione e sull'hardware del kernel specifici ... PTI avrebbe dovuto in gran parte essere mitigato da ASID, ad eccezione del software che chiama molto frequentemente nel kernel, l'esempio principale è rappresentato dai database, ma non ho una buona conoscenza dei numeri .

La speranza di Molnar nella patch RFC originale era che con il tempo "sarà probabilmente abilitato dalla maggior parte delle distribuzioni Linux". Ho notato che Fedora 28 fornisce un kernel predefinito creato con il NO_HZ_FULLsupporto. Debian 9 non lo fa, tuttavia.

Più recentemente, Linux v4.17 rimuove dalle nohz_fullCPU un tick residuo di 1 Hz residuo . Immagino che l'effetto sul throughput sia piuttosto piccolo :-), ma ho cercato di seguire lo stato dei NO_HZ_FULLvantaggi quando ci sono più processi eseguibili su una CPU:

una volta che raggiungiamo 0 Hz possiamo [quindi] rimuovere anche l'assunzione di tick periodici da nr_running> = 2, interrompendo essenzialmente le attività occupate con la stessa frequenza richiesta dai vincoli sched_latency - una volta ogni 4-40 msec, a seconda di nr_running .

Ciò è un po 'confuso poiché la prelazione è già iniziata utilizzando un tick separato, più preciso indietro in v2.6.25-rc1, commit 8f4d37ec073c, "sched: tick preemption ad alta risoluzione" . Trovato tramite questo commento sullo stesso articolo di LWN.net: https://lwn.net/Articles/549754/ ).