Dubbi su come funziona un computer (PER INGEGNERI)

[_?_]

sono uno studente delle superiori (ITIS indirizzo informatico) e sto studiando in questo periodo la struttura di un sistema operativo e mi sono sorte alcune domande sull'os e sul pc (assumiamo di star parlando di computer mono core):
1) come viene eseguito lo scheduler?
essendo lo scheduler un'applicazione come tante altre, essa dovrebbe esser eseguita dalla stessa cpu che esegue tutte le altre applicazioni, ma essendo lo scheduler a gestire i vari processi, da cosa viene gestito lo scheduler? ad esempio se in un sistema in cui lo scheduler ad esempio segue l'algoritmo Round Robin, come fa a rendersi conto che il time slice è scaduto se in esecuzione c'è un'altro processo? essendo impossibile che lo scheduler sia in esecuzione contemporaneamente ad un'altro programma, è necessario che lo scheduler ed il programma siano alternati nell'esecuzione?
e con gli altri algoritmi di scheduling, come fa a capire se è stato aggiunto un programma con maggiore priorità se in esecuzione c'è un'altro programma e non lo scheduler? possibile esista un time slice per lo scheduler che in tutti i sistemi multiprogrammati, fa subentrare nella cpu la sua esecuzione? e se esiste, da cosa è gestito? e se non esiste in che modo lo scheduler è "sempre" in esecuzione?
2) essendo ogni istruzione, ogni programma, ogni data, ecc…, come fa il processore a elaborare istruzioni ad oltre 2 ghz se la ram è più lenta? ad esempio il mio computer lavora a 2.4 Ghz ed su una scheda madre che lavora a 1 Ghz c'è la ram a 667Mhz ddr2, il mio dubbio è dunque il seguente, se il processore deve elaborare un programma prendendo delle istruzioni fino ad ora non eseguite (e quindi non presenti il cache) deve recuperare dalla memoria centrale i dati e le istruzioni, ma lavorando il processore a 2.4 ghz e la ram a 667 mhz il processore non dovrebbe riuscire ad elaborare ad una velocità maggiore a quella della ram per cui come è possibile che lavori al 100%?
3) dal dubbio derivato dalla seconda domanda e dalla prima mi vengono spontanei maggiori dubbi, in quanto, essendo lo scheduler una applicazioni che ha i suoi dati (le code pronti ed attesa) in memoria centrale, è sul serio possibile che ogni poco lo scheduler si metta ad interrogare la memoria che è così lenta?
4) se ci fosse una periferica che appena ricevuto un segnale, ne da subito un'altro come risposta, e che abbia una frequenza pari a quella della scheda madre, (sempre facendo riferimento alle caratteristiche elencate prima) essa sarebbe più veloce della memoria centrale, eppure è una periferica e trattata come tale, nonostante la messa in coda di attesa nella memoria centrale del programma che ne ha fatto richiesta, sia più lenta della risposta della periferica, è possibile? e se così fosse perché la memoria centrale non viene definita come periferica di input output se la sua velocità non è maggiore ad alcune periferiche? ma considerarla tale implicherebbe in paradosso della coda di attesa. per cui è sul serio possibile che la ram sia così lenta? e se non lo fosse come fa a non esserlo se la sua frequenza è così bassa? inoltre qual'è lo scopo di diffondere delle ram più veloci (tipo le ddr3) su schede madri che non sono sufficentemente veloci? e qual'è lo scopo di usare cpu ad elevate frequenze se ogni interazione con la scheda madre avviene ad una frequenza molto più bassa?

se fosse possibile, qualcuno saprebbe rispondere a questi dubbi citando se possibile anche le fonti?
grazie

[idoido]

tutte e 4 ottime domande, purtroppo i miei ricordi di sistemi operativi e calcolatori elettronici sono ormai pochi

comunque

riguardo domanda numero 2: la risposta è la pipeline, pagina wiki (http://it.wikipedia.org/wiki/Pipeline_dati) in pratica si parallelizzano alcune operazioni.

domanda numero 3: lo scheduler naturalmente tende a tenere i suoi dati in cache, considera poi che le cpu attualmente hanno 3 livelli di cache, comunque consiglio una lettura anche di http://it.wikipedia.org/wiki/CPU_cache

spero che qualche laureato più fresco ti dia risposte più esaurienti

[Yaro86]

Originariamente inviato da _?_

per ingegneri

No ing, no party

[Dimension7]

Per la domanda numero 2, è uno dei motivi per cui esiste la memoria cache. Mentre il processore si lavora le istruzioni che ha nei registri, la cache (ipotizzando ci sia solo un livello di cache, nei processori moderni ce ne sono 3 in genere) interroga la memoria per farsi passare le istruzioni successive. Chiaramente il tutto è complicato da istruzioni condizionali e di salto, nel senso che se in questo istante il processore ha nei registri l'istruzione 1000, la cache non sa a prescindere se la prossima istruzione sarà la 1001, o invece ci sarà un salto alla istruzione 1500 (numeri sparati a caso).
Non ricordo sinceramente com'è gestita questa eventualità.

Riguardo lo scheduler, è il sistema operativo che si occupa di gestire i programmi e le priorità, quindi se ci sono più programmi concorrenti ne fa fare prima un pezzetto ad uno, poi un pezzetto ad un altro etc (spiegato proprio in parole povere).

Non ho capito la domanda 4, che c'entra la scheda madre?

[_?_]

con la domanda 4 intendo dire che se c'è una periferica con una frequenza pari q quella della scheda madre, sarebbe più veloce della ram (nel mio caso ddr2) e quindi non mi spiego perché non venga anche la ram stessa considerata una i/o se in alcuni casi può essere più lenta di una vera periferica.

dunque tutte le code tipo pronti ed attesa sono in cache?

e il pipeline permette di caricare le istruzioni mentre le esegue, ma se tutto il programma fosse caratterizzato da una lunga serie di salti, allora sarebbe comunque possibile che il prefetch carichi tutte le istruzioni per far si che il processore lavori alla sua massima frequenza? cioè se ci fossero tutti salti e dunque il prefetch non carica le istruzioni necessarie, allora avremmo un processore che lavora alla velocità della ram?

comunque proprio riferito al farne fare un pezzetto ad uno ed un pezzetto all'altro, mi chiedo come faccia lo scheduler a deciderlo, cioè lo scheduler deve essere in esecuzione affinché possa stabilire a chi cedere la cpu, e una volta che la cede, come ci rientra?

[!fazz]

Originariamente inviato da _?_

con la domanda 4 intendo dire che se c'è una periferica con una frequenza pari q quella della scheda madre, sarebbe più veloce della ram (nel mio caso ddr2) e quindi non mi spiego perché non venga anche la ram stessa considerata una i/o se in alcuni casi può essere più lenta di una vera periferica.

dunque tutte le code tipo pronti ed attesa sono in cache?

e il pipeline permette di caricare le istruzioni mentre le esegue, ma se tutto il programma fosse caratterizzato da una lunga serie di salti, allora sarebbe comunque possibile che il prefetch carichi tutte le istruzioni per far si che il processore lavori alla sua massima frequenza? cioè se ci fossero tutti salti e dunque il prefetch non carica le istruzioni necessarie, allora avremmo un processore che lavora alla velocità della ram?

comunque proprio riferito al farne fare un pezzetto ad uno ed un pezzetto all'altro, mi chiedo come faccia lo scheduler a deciderlo, cioè lo scheduler deve essere in esecuzione affinché possa stabilire a chi cedere la cpu, e una volta che la cede, come ci rientra?

una periferica non potrai mai essere più veloce della ram per svariati motivi il primo dei quali è che la periferica comunica con la ram di sistema e la seconda è che i vari bus sono più lenti della ram

[Dimension7]

Per i salti, dipende da come sono gestiti dal processore (credo dipenda strettamente dall'architettura). Il processore "sa" a prescindere quale sarà l'istruzione successiva, se il salto verrà fatto o no. Nel senso, se alla riga 1000 c'è un if, il processore sa che se l'if sarà true eseguirà la riga 1001, se sarà false eseguirà la riga 1800. Se la gestione del salto è "ottimista", nella cache ci sarà l'istruzione 1001 (e 1002 etc), se la gestione del salto è "pessimista" in cache ci sarà l'istruzione 1800, 1801 etc. In un'ipotetica istruzione di tutti salti condizionati, la velocità dipenderà dall'eventualità che l'architettura coincida con la maggior parte dei salti, cioè se la gestione è ottimista e la maggior parte dei salti condizionati non si fanno, hai velocità massima (lo stesso se la gestione è pessimista e la maggior parte dei salti non viene effettuata), ma questo non si può sapere a prescindere.

Se invece nel codice ci sono salti incondizionati, per la macchina non cambia nulla, già sa che se alla riga 1000 c'è l'istruzione JMP 1800, dopo l'istruzione 1000 dovrà fare la 1800, perciò caricherà nella cache quella. Questo semplificando molto, in realtà poi dipende dalla gestione della cache, perchè in genere vengono prelevati blocchi di istruzioni, da quel che ricordo, quindi magari anche se c'è un jump all'istruzione 1000, in cache già avevo caricato le istruzioni 996-1004, ipotizzando che prende un byte alla volta.

Sullo scheduler non so aiutarti, sulla velocità delle periferiche ti ha risposto fazz. In pratica, per quanto tu abbia tecnologie avanzate per le periferiche, esse andranno comunque più piano della memoria centrale. I bus sono più "lunghi", perciò più lenti (più un filo è lungo più c'è il rischio di sporcare il segnale alzando la velocità, cioè un 1 potrebbe arrivare come 0 e viceversa).

[_?_]

effettivamente se le periferiche colloquiassero con la ram alcune cose avrebbero più senso

anche per quanto riguarda la cache la cosa sembra avere senso, e dunque in via definitiva le code sono in cache e non in ram? confermando ciò molti dobbi hanno risposta, ma alla fine rimane il problema dello scheduler

[Dimension7]

Sarebbe pericoloso invece, in questo modo non è il processore ad avere controllo della ram, ma un agente esterno. Immagina, il processore salva un dato di un programma in un certo indirizzo della RAM, arriva la periferica X e sovrascrive quell'indirizzo con qualche altro valore, una volta che il processore torna ad utilizzare quell'indirizzo, si ritrova un valore diverso da quello che aveva scritto lui, sbarellando tutto il programma.

Poi credo ci sarebbero anche dei problemi a livello architetturale.

[!fazz]

Originariamente inviato da Dimension7

Sarebbe pericoloso invece, in questo modo non è il processore ad avere controllo della ram, ma un agente esterno. Immagina, il processore salva un dato di un programma in un certo indirizzo della RAM, arriva la periferica X e sovrascrive quell'indirizzo con qualche altro valore, una volta che il processore torna ad utilizzare quell'indirizzo, si ritrova un valore diverso da quello che aveva scritto lui, sbarellando tutto il programma.

Poi credo ci sarebbero anche dei problemi a livello architetturale.

guarda che le periferiche possono colloquiare direttamente con la ram ma ovviamente avviene sotto controllo della cpu che inizia il trasferimento che viene poi gestito dal dma controller (il famoso agente esterno )


ma mi sa che gli stiamo incasinando la vita

[hibone]

Originariamente inviato da _?_

1) come viene eseguito lo scheduler?

Dipende dallo scheduler e dall'hardware. In linea generale il puntatore a istruzione della cpu referenzia l'istruzione da eseguire e ad ogni colpo di clock passa a quella successiva. esattamente come per qualsiasi altro software.

essendo lo scheduler un'applicazione come tante altre, essa dovrebbe esser eseguita dalla stessa cpu che esegue tutte le altre applicazioni, ma essendo lo scheduler a gestire i vari processi, da cosa viene gestito lo scheduler?

Come sopra, dipende dall'hardware.

Anche considerando le cpu single core esistono molteplici architetture e molteplici linguaggi macchina, non esiste una risposta univoca.

Tieni presente che le moderne cpu fanno uso di microcodice ( ovvero un firmware)
http://en.wikipedia.org/wiki/Microcode

ed è sostanzialmente differente dallo scheduler che è associato invece allo specifico sistema operativo.

In altri termini possono esistere casi in cui lo scheduler agisce direttamente sulla cpu, e casi in cui tra la cpu e lo scheduler è interposto codice di varia natura e origine, come ad esempio il codice usato per permettere la virtualizzazione, con riferimento alle architetture degli anni 70 - 90, ovviamente, non certo alle tecnologie di oggi.

Sinceramente quasi mai vale la pena conoscere quale architettura ha usato quale soluzione, per cui quando serve saperlo, è preferibile fare riferimento a dei buoni libri di testo di riferimento su sistemi operativi sistemi di elaborazione e reti di calcolatori, tra i tanti puoi vedere ad esempio il tanenbaum o il silberschatz tra i più famosi.

ad esempio se in un sistema in cui lo scheduler ad esempio segue l'algoritmo Round Robin, come fa a rendersi conto che il time slice è scaduto se in esecuzione c'è un'altro processo? essendo impossibile che lo scheduler sia in esecuzione contemporaneamente ad un'altro programma, è necessario che lo scheduler ed il programma siano alternati nell'esecuzione?

Generalmente fa uso di meccanismi di controllo, quali ad esempio gli interrupt, messi a disposizione dalla cpu.

e con gli altri algoritmi di scheduling, come fa a capire se è stato aggiunto un programma con maggiore priorità se in esecuzione c'è un'altro programma e non lo scheduler?

come sopra, dipende. le soluzioni più comuni prevedono l'uso di interrupt o in alternativa una verifica periodica dello stato dell'hardware.

possibile esista un time slice per lo scheduler che in tutti i sistemi multiprogrammati, fa subentrare nella cpu la sua esecuzione? e se esiste, da cosa è gestito? e se non esiste in che modo lo scheduler è "sempre" in esecuzione?

Penso di averti già risposto sopra, tieni conto comunque che la time slice è la ripartizione dei tempi, quindi da sola fa ben poco.

2) essendo ogni istruzione, ogni programma, ogni data, ecc…, come fa il processore a elaborare istruzioni ad oltre 2 ghz se la ram è più lenta?

tu stesso parli di cache da qualche parte. dovresti avere già la risposta.

ad esempio il mio computer lavora a 2.4 Ghz ed su una scheda madre che lavora a 1 Ghz c'è la ram a 667Mhz ddr2, il mio dubbio è dunque il seguente, se il processore deve elaborare un programma prendendo delle istruzioni fino ad ora non eseguite (e quindi non presenti il cache) deve recuperare dalla memoria centrale i dati e le istruzioni, ma lavorando il processore a 2.4 ghz e la ram a 667 mhz il processore non dovrebbe riuscire ad elaborare ad una velocità maggiore a quella della ram per cui come è possibile che lavori al 100%?

questa esemplificazione semplicemente non ha senso perché tagli via dei pezzi. andiamo per passi:

ad esempio il mio computer lavora a 2.4 Ghz ed su una scheda madre che lavora a 1 Ghz c'è la ram a 667Mhz ddr2,

Prima osservazione: Il "significato" della frequenza di clock varia da dispositivo a dispositivo.

Per una cpu potrebbe rappresentare anche il numero di istruzioni per unità di tempo, anche se non è affatto detto che lo rappresenti, occorre considerare il pipelining, branching il tipo di architettura e quant'altro
Per la ram potrebbe rappresentare il traffico dati, ma di nuovo non è detto che lo rappresenti. Occorre considerare la dimensione del bus, la politica di gestione, il tipo di ram e via dicendo.

Inoltre, comunque la si metta, dato che processore e ram non comunicano direttamente, non c'è bisogno che facciano uso della stessa frequenza di bus.

il mio dubbio è dunque il seguente, se il processore deve elaborare un programma prendendo delle istruzioni fino ad ora non eseguite (e quindi non presenti il cache) deve recuperare dalla memoria centrale i dati e le istruzioni,

benissimo.
( per inciso la cache contiene sempre anche istruzioni non eseguite )

ma lavorando il processore a 2.4 ghz e la ram a 667 mhz il processore non dovrebbe riuscire ad elaborare ad una velocità maggiore a quella della ram per cui come è possibile che lavori al 100%?

sei passato dall'osservazione sopra a questa con un volo pindarico.

Se prima le istruzioni che il processore esegue stanno su cache, perchè poi dovrebbero risiedere su ram? le istruzioni che il processore esegue stanno stanno sempre su cache, hai saltato il passaggio in cui il processore segnala al controller della memoria di recuperare i dati dalla memoria centrale per copiarli nella cache, previo svuotamente della porzione di cache occupata dalle istruzioni già eseguite.

3) dal dubbio derivato dalla seconda domanda e dalla prima mi vengono spontanei maggiori dubbi, in quanto, essendo lo scheduler una applicazioni che ha i suoi dati (le code pronti ed attesa) in memoria centrale, è sul serio possibile che ogni poco lo scheduler si metta ad interrogare la memoria che è così lenta?

ma perché ti scordi sempre la cache? Perchè disturbarsi ad inventare la cache, se il processore può usare direttamente la ram?

4) se ci fosse una periferica che appena ricevuto un segnale, ne da subito un'altro come risposta, e che abbia una frequenza pari a quella della scheda madre, (sempre facendo riferimento alle caratteristiche elencate prima) essa sarebbe più veloce della memoria centrale,

su cosa basi questa tua affermazione? generalmente è errata.
la ram viaggia alla stessa frequenza del bus primario della scheda madre. tutte le altre periferiche o si connettono al bus primario, e quindi vanno veloci al più quanto la ram o meno, oppure si connettono al bus secondario, e quindi vanno più lente.

inoltre con le cpu che abbiano il controller della memoria integrato, le ram hanno un bus riservato la cui velocità è generalmente superiore rispetto a quella di tutte le altre periferiche.

eppure è una periferica e trattata come tale, nonostante la messa in coda di attesa nella memoria centrale del programma che ne ha fatto richiesta, sia più lenta della risposta della periferica, è possibile?

non si capisce quello che vuoi dire. il controller che gestisce le periferiche può operare in vari modi, può essere asincrono e far uso di segnali di controllo, può essere sincrono ed eseguire il polling e via dicendo. le possibilità sono infinite. Solitamente quando la memoria e le altre periferiche condividono il bus, le richieste vengono avviate senza attendere risposta. man mano che le operazioni richieste alle periferiche vengono completate i dati vengono trasmessi. Chi viene prima? chi viene dopo? boh. dipende. se ad esempio il controller utilizza una trasmissione a pacchetti, il blocco di dati da trasmettere da ciascuna sorgente viene spezzettato e i pacchetti possono essere prelevati a rotazione, per cui i dati vengono trasmessi assieme e non c'è di fatto un prima o un dopo. questo chiaramente è un esempio, non è detto che su una macchina avvenga.

alcune o molte delle cose che ho scritto puoi trovarle sulle fonti riportate qui:
http://en.wikipedia.org/wiki/Advance...specifications

e se così fosse perché la memoria centrale non viene definita come periferica di input output

Perchè fino a prova contraria non sei in grado di inserire i dati direttamente nella memoria del pc. Una periferica di I/O ( AIO' in sardo ) è per definizione una periferica che permette al pc di interagire col mondo esterno, e la ram non rientra tra queste.

ma considerarla tale implicherebbe in paradosso della coda di attesa.

no. considerarla tale implicherebbe un paradosso nella testa di chi la definisce periferica di I/O.

per cui è sul serio possibile che la ram sia così lenta?

ne parli come se debba essere un'assurdità. ma perché non può essere lenta? Voglio dire i pc funzionano senza problemi anche con ram lente, e il tutto è perfettamente spiegabile. Cosa c'è di così inaccettabile? Voglio dire, non credo che ti sia mai venuto in mente di sindacare sulla velocità del metabolismo di un tuo conoscente.

e se non lo fosse come fa a non esserlo se la sua frequenza è così bassa?

Ti ho già risposto sopra.

inoltre qual'è lo scopo di diffondere delle ram più veloci (tipo le ddr3) su schede madri che non sono sufficentemente veloci?

ridurre le latenze, prima ancora di aumentare il throughtput ( spero di averlo spellato bene )

e qual'è lo scopo di usare cpu ad elevate frequenze se ogni interazione con la scheda madre avviene ad una frequenza molto più bassa?

Te lo lascio come compito per casa.

PS.
non sono ingegnere.

[hibone]

Originariamente inviato da Dimension7

Sarebbe pericoloso invece, in questo modo non è il processore ad avere controllo della ram, ma un agente esterno. Immagina, il processore salva un dato di un programma in un certo indirizzo della RAM, arriva la periferica X e sovrascrive quell'indirizzo con qualche altro valore, una volta che il processore torna ad utilizzare quell'indirizzo, si ritrova un valore diverso da quello che aveva scritto lui, sbarellando tutto il programma.

Poi credo ci sarebbero anche dei problemi a livello architetturale.

DMA = direct memory access

[Dimension7]

Si scusate, dimenticavo il dmac

[_?_]

effettivamente dopo arrivati a questo punto più o meno o capito la parte relativa alla ram, cpu e cache, ma se tutte le code sono in cache, non ci sarebbe un limite abbastanza piccolo che la coda potrebbe raggiungere?
ad ogni la parte sullo scheduler ancora non mi torna, avrebbe senso se periodicamente interrogherebbe l'hardware, come è stato detto sopra, ma come fa a sapere quando questo tempo è finito? con che meccanismo? tipo conoscete un'esempio adottato da qualche architettura?

[hibone]

Originariamente inviato da _?_

effettivamente dopo arrivati a questo punto più o meno o capito la parte relativa alla ram, cpu e cache, ma se tutte le code sono in cache, non ci sarebbe un limite abbastanza piccolo che la coda potrebbe raggiungere?
ad ogni la parte sullo scheduler ancora non mi torna, avrebbe senso se periodicamente interrogherebbe l'hardware, come è stato detto sopra, ma come fa a sapere quando questo tempo è finito? con che meccanismo? tipo conoscete un'esempio adottato da qualche architettura?

puoi cercare qualche dettaglio sugli interrupt.

[_?_]

ma se è un'interupt che non viene da nessun programma in esecuzione, allora è derivante da un circuito? ma non dovrebbe essere interamente software?

[Marinelli]

Gli interrupt possono arrivare anche dall'hardware... per esempio da una periferica.

Ciao.

[!fazz]

Originariamente inviato da _?_

ma se è un'interupt che non viene da nessun programma in esecuzione, allora è derivante da un circuito? ma non dovrebbe essere interamente software?

no, esistono interrupt software e interrupt hw utilizzati per la gestione asincrona delle periferiche (es la tastiera, ad ogni tasto premuto genera un interrupt )

[_?_]

ok, ora alla fine ho una visione un po' più chiara, grazie a tutti per le risposte

[nushuth]

Originariamente inviato da Dimension7

Per la domanda numero 2, è uno dei motivi per cui esiste la memoria cache. Mentre il processore si lavora le istruzioni che ha nei registri, la cache (ipotizzando ci sia solo un livello di cache, nei processori moderni ce ne sono 3 in genere) interroga la memoria per farsi passare le istruzioni successive. Chiaramente il tutto è complicato da istruzioni condizionali e di salto, nel senso che se in questo istante il processore ha nei registri l'istruzione 1000, la cache non sa a prescindere se la prossima istruzione sarà la 1001, o invece ci sarà un salto alla istruzione 1500 (numeri sparati a caso).
Non ricordo sinceramente com'è gestita questa eventualità.

Qui posso intervenire io, anche se non sono laureato.. per tutto il resto è stato comunque risposto, direi...

dentro le moderne CPU esiste un circuito di "prediction branch" che si occupa di predire quali dati e istruzioni il core avrà bisogno successivamente. di solito durante le operazioni vero/falso questo circuito tenta di prevedere il comportamento sia un una che nell'altra ipotesi, e cerca di indovinare quale delle due possibilità (vero o falso) sia piu brobabile che accada.

capita però che a volte questo prediction branch commetta delgi errori, e che le ipotesi che ha fatto siano completamente errate o disattese. in questo caso l'esecuzione del codice si blocca per qualche ciclo di clock, la cache interna della CPU viene completamente svuotata e l'esecuzione riprende, con la prediction branch che ricomincia il suo lavoro.

quanto a scheduler e tutto il resto: ricorda che lo scheduler è sua un "pezzo di SW come tutto il resto, ma è integrato direttamente nel kernel. in pratica, è un "supervisore" di tutti gli altri processi che vengono eseguiti.. al suo interno sono presenti dei cosiddetti "semafori" ed hook con cui è possibile interagire con esso, chiedere risorse, permessi e controlli.