Come conoscere il time slice del programmatore di Linux?

Question

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?

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

Grazie in anticipo.

Answer 1

Il timeslice Linux predefinito per i processi in tempo reale è 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) 

Si noti che il quantum effettivo assegnato per un particolare processo may be different di questo valore:

È possibile sintonizzarsi "fetta" regolando sched_latency_ns e sched_min_granularity_ns, ma nota che "slice "non è un valore fisso . Si noti inoltre che le decisioni di prelazione CFS sono basate sullo stato istantaneo . Un'operazione potrebbe aver ricevuto una "slice" completa (variabile) di tempo CPU, ma la prelazione verrà attivata solo se è disponibile un ulteriore task meritevole , quindi una "slice" non è il "max tempo CPU ininterrotto" che potrebbe aspettarsi che sia .. ma è in qualche modo simile.

Tuttavia, è possibile utilizzare sched_rr_get_interval() per ottenere l'intervallo SCHED_RR per un dato processo in tempo reale.

Answer 2

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 compreso tra sysctl_sched_min_granularity e sysctl_sched_latency, che sono predefiniti rispettivamente a 0,75 ms e 6 ms e definiti in kernel/sched/fair.c.

Ma timeslice effettivo non viene esportato nello spazio utente.

Answer 3

C'è una certa confusione nella risposta accettata tra i processi SCHED_OTHER (vale a dire, quelli che operano con il criterio (non predefinito in tempo reale round-robin round-robin) e i processi SCHED_RR.

I sched_latency_ns e sched_min_granularity_ns file (che siano destinati a fini di debug, e visibili solo se il kernel è configurato con CONFIG_SCHED_DEBUG) influenzano la schedulazione 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 è garantito ottenere un processo SCHED_RR, a meno che non sia preceduto o blocchi. Su Linux tradizionale, il valore SCHED_RR è di 0,1 secondi.Dal momento che Linux 3.9, il limite è /proc/sys/kernel/sched_rr_timeslice_ms, il quantum è espresso come un valore in millisecondi il cui valore predefinito è 100.

Answer 4

Ho cercato su Google questo ticket circa lo stesso dubbio sulla porzione di tempo di SCHED_RR. Ma non riesco a ottenere una risposta chiara sia da qui che dal codice sorgente del kernel. Dopo ulteriori controlli, 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", quale valore di ingresso in millisecondo, ma archiviare e generare in jiffies! Quindi, quando CONFIG_HZ = 100, troverai:

# 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!