Linuxtrent: Re: Timeslice in Linux
- From: "Gelpi Andrea" <ggelpi@xxxxxx>
- To: <linuxtrent@xxxxxxxxxxxxxxxxx>
- Date: Fri, 27 Apr 2001 09:28:33 +0200
Posso solo fare un discorso generale, valido per tutti i SO.
Lo scheduler di solito viene attivato in base ad un interrupt a tempo.
Prende in esame la coda dei processi in stato di Ready (cioe pronti ad
eseguire istruzioni) calcola la priorita e prende quello con priorita piu
alta e gli da il controllo.
Ovviamente l'attivita dello scheduler consuma sia tempo che risorse.
Piu alta e la frequenza e piu alta e la reattivita del sistema, ma il prezzo
che si paga e che aumenta il peso dell'attivita dello scheduler.
Ricordo che nel 1980 su un PDP-11 ci divertivamo a far partire processi a
gogo fino a saturare lo slice time del sistema, in modo da ottenere un DoS
del sistema che passava tutto il suo tempo con lo scheduler attivo e non
aveva tempo per lavorare. Risultato sistema fermo.
Aumentando la frequenza dello scheduler si riduce lo slice di tempo di ogni
processo e aumenta la percentuale di tempo di inutilizzo del sistema.
Sui mainframe IBM il valore e settato a 20ms cioe 50Hz e puo essere variato
fra 100ms e 3 ms.
Personalmente ritengo che sia un valore che va variato in funzione dell'uso
che si fa del sistema.
Su sistemi con moltissimi processi attivi (cioe Reday) contemporaneamente
puo aver senso alzare tale frequenza, su sistemi per uso casalingo dove di
fatto i processi ready contemporaneamente sono pochi forse e piu furbo
ridurlo.
Non so dirvi di preciso in Linux, ma va inoltre tenuto conto che puo essere
che il processo attivo in uno slice time se si sospende (per esempio a causa
di una operazione di I/O) il tempo rimanente dello slice time non venga
utilizzato da nessuno. Quindi allungare lo slice time significa aumentare la
probabilita di attimi di cpu ferma.
Per contro uno slice time troppo piccolo, porta ad un aumento del tempo di
lavoro dello scheduler (che di fatto e tempo morto).
Sarebbe utile avere delle statistiche sia puntuali (valori medi ogni circa
30 secondi) sia medie delle medie (ogni 5 minuti e ogni ora) con valori di
utilizzo della CPU divisa in tempo utente di sistema e scheduler per poter
fare delle ulteriori considerazioni.
Non so se Linux ha a disposizione tali informazioni.
Se serve sono a disposizione per fare un'analisi di eventuali dati che
riuscite a procurarvi (in fondo faceva parte del mio lavoro sui mainframe
IBM fino a 3 anni fa).
Andrea Gelpi
> -----Original Message-----
> From: linuxtrent-bounce@xxxxxxxxxxxxxxxxx
> [mailto:linuxtrent-bounce@xxxxxxxxxxxxxxxxx]On Behalf Of
> matteoianeselli@xxxxxxxxxxx
> Sent: martedi 24 aprile 2001 20.34
> To: linuxtrent@xxxxxxxxxxxxxxxxx
> Subject: Linuxtrent: Timeslice in Linux
>
>
>
>
> Leggo in un commento su Slashdot
> (http://slashdot.org/comments.pl?sid=01/04/24/1551243&cid=51)
>
> che sarebbe possibile cambiare nei sorgenti del kernel la frequenza
> con cui lo scheduler di Linux passa da un processo all'altro, e che
> aumentando la frequenza (i.e. da 100Hz a 1024Hz) si puo` ottenere un
> sistema che, almeno a occhio, e` piu` "reattivo" (quantomeno su
> macchine che hanno una certa velocita`). Nel thread alcuni vantano
> mirabilia, ma chiaramente dipende da come uno usa il computer...
>
> Il valore, per le macchine x86, e` in
>
> /usr/src/linux/include/asm-i386/param.h
>
> ed e` definito dalla macro C
>
> #define HZ 100
>
> che ad esempio potrebbe essere cambiata in
>
> #define HZ 1024
>
> (non deve essere necessariamente una potenza di 2, dopotutto 100 non
> lo e`, ma da un'occhiata *rapidissima* nel kernel sembrerebbe che sia
> preferibile in alcuni casi, per cui... male non fa).
>
> Qualcuno conosce meglio la faccenda?
> --
> Matteo Ianeselli
> matteoianeselli AT poboxes.com
> --
> Per iscriversi (o disiscriversi), basta spedire un messaggio
> con SOGGETTO
> "subscribe" (o "unsubscribe") a
mailto:linuxtrent-request@xxxxxxxxxxxxxxxxx
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxxxxxx
Other related posts: