Come sapere la fasce orarie del programmatore linux?

Sto cercando il valore della porzione temporale (o quantistica) del mio kernel Linux.

Esiste un file /proc che espone tali informazioni?

(O) È ben definito nell’intestazione Linux delle mie distribuzioni?

(O) Esiste una funzione C dell’API di Linux (forse sysinfo) che espone questo valore?

Grazie in anticipo.

Il quantum allocato per un particolare processo può variare :

È ansible regolare “slice” regolando sched_latency_ns e sched_min_granularity_ns , ma si noti che “slice” non è un quantum fisso. Si noti inoltre che le decisioni di prelazione della CFS sono basate sullo stato istantaneo. Un’attività può aver ricevuto una “slice” completa (variabile) di tempo CPU, ma la preemption verrà triggersta solo se è disponibile un’attività più meritevole, quindi una “slice” non è la “durata massima della CPU ininterrotta” che è ansible aspettarsi essere .. ma è in qualche modo simile.

Per i processi in tempo reale ad uso speciale che utilizzano SCHED_RR, il timeslice predefinito è definito nel kernel Linux come RR_TIMESLICE in include / linux / sched / rt.h.

 /* * default timeslice is 100 msecs (used only for SCHED_RR tasks). * Timeslices get refilled after they expire. */ #define RR_TIMESLICE (100 * HZ / 1000) 

È ansible utilizzare sched_rr_get_interval() per ottenere l’intervallo SCHED_RR per un processo SCHED_RR specifico.

CFS (che è il programma di pianificazione predefinito per i processi) non ha un timeslice fisso, viene calcolato in fase di esecuzione in base alla latenza di destinazione ( sysctl_sched_latency ) e al numero di processi in esecuzione. Timeslice non può mai essere inferiore alla granularità minima ( sysctl_sched_min_granularity ).

Timeslice sarà sempre tra sysctl_sched_min_granularity e sysctl_sched_latency , che sono predefinite rispettivamente a 0,75 ms e 6 ms e definite in kernel / sched / fair.c.

Ma l’attuale timeslice non viene esportato nello spazio utente.

C’è una certa confusione nella risposta accettata tra i processi SCHED_OTHER (cioè quelli che operano secondo il criterio (non predefinito in tempo reale round-robin round-robin) e i processi SCHED_RR .

I file sched_latency_ns e sched_min_granularity_ns (destinati a scopi di debug e visibili solo se il kernel è configurato con CONFIG_SCHED_DEBUG ) influenzano la pianificazione dei processi SCHED_OTHER . Come notato nella risposta di Alexey Shmalko, la porzione temporale sotto CFS non è fissa (e non viene esportata nello spazio utente), e dipenderà dai parametri del kernel e da fattori come il valore piacevole del processo.

sched_rr_get_interval () restituisce un valore fisso che è il quantum che un processo SCHED_RR è garantito per ottenere, a meno che non sia preventivato o blocchi. Sul Linux tradizionale, il quantum di SCHED_RR è di 0,1 secondi. Dal momento che Linux 3.9, il limite è regolabile tramite il file /proc/sys/kernel/sched_rr_timeslice_ms , dove il quantum è express come un valore in millisecondi il cui valore predefinito è 100.

Ho cercato su Google questo ticket sullo stesso dubbio sulla porzione temporale di SCHED_RR in Linux. Ma non riesco a ottenere una risposta chiara sia da qui che dal codice sorgente del kernel. Dopo un ulteriore controllo, ho trovato che il punto chiave è “RR_TIMESLICE” è la sezione temporale predefinita in jiffies , non millisecondo! Pertanto, la fascia oraria predefinita di SCHED_RR è sempre di 100 ms, indipendentemente dal tipo di HZ configurato.

Uguale al valore di “/ proc / sys / kernel / sched_rr_timeslice_ms”, che immette il valore in millisecondi , ma memorizza ed emette in jiffies ! Quindi, quando CONFIG_HZ = 100, troverai che:

 # echo 100 > /proc/sys/kernel/sched_rr_timeslice_ms # cat /proc/sys/kernel/sched_rr_timeslice_ms 10 

È un po ‘confuso. Spero che questo possa aiutarti a capirlo!