Linus attacca Linux

[frakka]

Cacchio ci credo che è veloce, scritto in assembly...


Il problema è che anche per gli utenti Linux è comodo collegare una pendrive USB e vedersela riconosciuta al volo senza penare tanto montarla a manina, installare il supporto USB, al filesystem. Ma queste comodità hanno un peso che si paga.

Monolitico o microkernel... Per ora la soluzione di Linux si è rivelata pagante. Non credo che dover richiamare centinaia di moduli solo per avere le stesse funzioni che ti rende disponibili un kernel monolitico sarebbe molto più efficiente. Certo, permetterebbe di richiamare solo quello che serve e non molte cose inutili per il sistema specifico ma questo si può fare anche su Linux, basta avere voglia di mettersi dietro a ricompilare il kernel... Ne avete voglia?? Per quello che può essere il miglioramento di prestazioni sul mio desktop io decisamente non ce l'ho.
Che poi il codice del kernel monolitico possa essere ottimizzato meglio sono d'accordo, c'è sempre spazio per migliorare.

[Plokko]

Cacchio ci credo che è veloce, scritto in assembly...


Il problema è che anche per gli utenti Linux è comodo collegare una pendrive USB e vedersela riconosciuta al volo senza penare tanto montarla a manina, installare il supporto USB, al filesystem. Ma queste comodità hanno un peso che si paga.

Monolitico o microkernel... Per ora la soluzione di Linux si è rivelata pagante. Non credo che dover richiamare centinaia di moduli solo per avere le stesse funzioni che ti rende disponibili un kernel monolitico sarebbe molto più efficiente. Certo, permetterebbe di richiamare solo quello che serve e non molte cose inutili per il sistema specifico ma questo si può fare anche su Linux, basta avere voglia di mettersi dietro a ricompilare il kernel... Ne avete voglia?? Per quello che può essere il miglioramento di prestazioni sul mio desktop io decisamente non ce l'ho.
Che poi il codice del kernel monolitico possa essere ottimizzato meglio sono d'accordo, c'è sempre spazio per migliorare.

Non hai capito che problemi ha un kernel non monolitico:
in un kernel non monolitico il kernel è spezzettato in varie parti,ad esempio prendiamo minix che di microkernel è estremista,il memory e program manager ad esempio è separato dal kernel vero e proprio;
OGNI VOLTA che il kernel deve accedere a una parte non "locale" del kernel deve mandare un messaggio(quindi c'è un'overheat per la scrittura,switch del programma e rilettura del messaggio)che è un'operazione sicuramente molto ma molto piu pesante che richiamare una funzione,contate pure che queste aree del kernel vengono richiamate anche centinaia di volte al secondo(tipo il program manager)e capirete che l'overhead è altissimo,mica per nulla minix ed altre strutture a microkernel puro sono e resteranno solo casi di studio.
Per la ricompilazione del kernel non capisco,perchè dovresti?
se non vuoi smanettare coi settaggi va gia bene,certo il kernel linux discosta per i moduli dal kernel monolitico "puro" ma lo fa solo per rendere la compatibilita driver piu semplice il che secondo me è il livello perfetto poichè come l'LVM introduce un piccolo rallentamento in favore di una grande ottimizzazione per l'interoperabilita lo stesso fanno i moduli per la compatibilta.

Per il resto che centra l'automount con il kernel?

[frakka]

No, lo avevo capito. Solo mi sono espresso male forse.

Per l'automount... Sono le due di notte anche per me. Però ero convinto che fosse una funzionalità integrata nel kernel, così come il supporto al filesystem e alle periferiche.

E cmq aggiungere queste funzionalità al sistema operativo (ok, si parlava solo di kernel ma va tutto di conseguenza) ha un peso che si paga in termini di "ingrasso" del sistema, che sia kernel o sistema operativo.

[Vincent Vega]

Alla fine, come dice Plokko, nel Microkernel son le comunicazioni tra "Host e client" che creano del grasso.

Per quel poco che ne so, il Kernel è come composto da un Host\Core, che immagino come il cuore del MicroKernel, e vari Client o i Cd. Moduli Servers. Ogni System Call al Kernel viene reindirizzata al Modulo Server, dopo la necessaria commutazione Ring 3-to-0 (Mi pare che avvenga solo con le CPU Intel) che consente l'autenticazione all'Hardware dell'Host\Kernel stesso, che, a sua volta reindirizza la chiamata al Modulo Server che, in fine, "esegue". I Client sono come dei "Plug-In" implementati con un certo grado di astrazione rispetto al Kernel stesso, di per se, "a livello utente". Come se, appunto, ci fosse un Core da cui dipendono dei servizi base che nell'insieme costituiscono un sistema operativo.

Mi vien da pensare ad aMuled+aMulegui+aMuleWeb.

Comunque, perché i moduli possano comunicare in modo opportuno, quindi limitando l'overhead nelle "trasmissioni", sarebbe necessario un limite di overflow (Un record di attivazione mi pare, ma non ne sono sicuro) oltre il quale il Core possa Killare il processo alla base dell'istruzione. Insomma, il Core dovrebbe integrare anche uno Scheduler (LOL, e meno male che è un Microkernel ). IMHO, solo nel caso di "Core-Servers" sviluppati per lavorare in Multitasking come Minix (Preemptive).

[Plokko]

Alla fine, come dice Plokko, nel Microkernel son le comunicazioni tra "Host e client" che creano del grasso.

Per quel poco che ne so, il Kernel è come composto da un Host\Core, che immagino come il cuore del MicroKernel, e vari Client o i Cd. Moduli Servers. Ogni System Call al Kernel viene reindirizzata al Modulo Server, dopo la necessaria commutazione Ring 3-to-0 (Mi pare che avvenga solo con le CPU Intel) che consente l'autenticazione all'Hardware dell'Host\Kernel stesso, che, a sua volta reindirizza la chiamata al Modulo Server che, in fine, "esegue". I Client sono come dei "Plug-In" implementati con un certo grado di astrazione rispetto al Kernel stesso, di per se, "a livello utente". Come se, appunto, ci fosse un Core da cui dipendono dei servizi base che nell'insieme costituiscono un sistema operativo.

Mi vien da pensare ad aMuled+aMulegui+aMuleWeb.

Comunque, perché i moduli possano comunicare in modo opportuno, quindi limitando l'overhead nelle "trasmissioni", sarebbe necessario un limite di overflow (Un record di attivazione mi pare, ma non ne sono sicuro) oltre il quale il Core possa Killare il processo alla base dell'istruzione. Insomma, il Core dovrebbe integrare anche uno Scheduler (LOL, e meno male che è un Microkernel ). IMHO, solo nel caso di "Core-Servers" sviluppati per lavorare in Multitasking come Minix (Preemptive).

chee??
per la cronaca minix è un sistema ULTRA ULTRA ULTRA base,il codice sorgente è fatto per essere poco e leggibile utilizzano le tecniche piu stupide e meno performanti solo per aumentare la semplicita poichè è solo un kernel DA STUDIARE come base(è la semplificazione del primissimo linux che poi venne completamente modificato).
Ovviamente le performance sono orrende e non ha nessun programma!
L'automount sembra piu un servizio demone(i demoni sono programmi lato utente che stanno in attesa di particolari eventi ad esempio il demone della stampa,occhio che lato utente è inteso qualsiasi programma non kernel non che non possa avere permessi di root)


eccovi un bello schemino di minix

Scusate se è fatto un po male ma è l'unica cosa che ho trovato in giro e nn avevo voglia di uploadare !
dove c'è la parentesi KERNEL è tutto un programma solo(il kernel integra clock task,disk...)
tutti gli altri programmi e demoni sono avviati in user level(anche memory manager per minix);per f esempio minix COME MINIMO(visto che il program manager è essenziale se vogliamo che giri qualcosa oltre al kernel) ogni tot nanosecondi il clock di sistema è configurato per mandare un interrupt che interrompe la routine in esecuzione e richiama il clock task,esso modifica l'ora del sistema(dopo aver salvato ovviamente i registri del programma che era in esecuzione)e richiama il process manager con un'ovvio altro content switch(content switch=LENTO,da evitare)che a sua volta prendera il prossimo programma da eseguire(non per forza un'altro se non ha finito il suo quanto di tempo)eseguendo ovviamente un'altro content switch.

Per quello che dici tu vega del richiamo ogni tot tempo di programmi(se ho capito cosa intendevi)c'è un demone che adempie a quello scopo e viene chiamato ogni tot secondi per vedere se c'è qualche programma in coda,per l'automount invece spero che venga usato l'interrupt della periferica.

Per farvi un'altro esempio di cosa non sia integrato nel kernel unix(con ottimi motivi)è il VFS(scusate ancora per l'immagine)

esso è un "layer di astrazione" per i filesystem,cioè consente un accesso uguale per tutti i file system.
Per esempio se parliamo di ext3 o di un file system strano di vostra invenzione i parametri per aprirlo,scrivere o leggere potrebbero essere radicalmente diversi e dovrebbero essere gestiti di caso in caso specificando il tipo di filesystem.
Con il VFS si hanno dei comandi standard per accedere al files.e sara il VFS a gestire come interpretare i comandi in base ai settaggi interni.
Questo porta ovviamente a un calo di prestazioni ma visto che i vantaggi in termini di portabilita ed espandibilita superano i problemi si puo anche rinunciare a un po di prestazioni senza rimorsi.

Come vedete sono fresco fresco di Sistemi Op.,mi sono interessato a fondo poichè fa veramente paura la quantita di cose che ci sta dietro a un s.o. o che vengono eseguite in un singolo momento,noi ci facciamo problemi se mettiamo due o tre righe in piu di codice quando il s.o. fa giri assurdi senza dircelo.

Per il tuo discorso frakka di base è giusto(cioè si sacrifica performance e si aggiunge codice per migliorare l'esperienza utente)e torvald non lo mette in discussione,la sua strigliata invece indica che si sta esagerando,quando windows inizia a diminuire di grandezza ed aumentare di perforamance linux fa il contrario,è bene non esagerare con sole features senza considerare il loro impatto prestazionale.

P.S.:per l'ora a cui hai scritto me n'ero accorto appena m'è arrivato l'up!

[Vincent Vega]

Quello che avrei voluto far intendere io sarebbe un controllo di Overflow "sulle comunicazioni" per limitare l'Overhead che si genera tra il Core ed i Moduli Server, affiancato da uno Scheduler, in ambienti Multitasking come Minix, capace di gestire un Record di attivazione per il completamento di istruzioni già aviate. Non si genererebbe troppo traffico per via dei Task eseguiti in rapida successione e se abbinato ad una buona potenza di calcolo potrebbe essere un approccio concorrenziale. Cercavo una soluzione all'Overhead che si genera nei Microkernel in parole povere. Che Minix sia basilare non c'è dubbio.

Sull'automount non so molto invece...

P.s.
Bei disegnini !!!

P.P.S.
Un sistema operativo dovrebbe essere essenziale e modulare, come dico io Tabbabile come Chrome ...

[Plokko]

Quello che avrei voluto far intendere io sarebbe un controllo di Overflow "sulle comunicazioni" per limitare l'Overhead che si genera tra il Core ed i Moduli Server, affiancato da uno Scheduler, in ambienti Multitasking come Minix, capace di gestire un Record di attivazione per il completamento di istruzioni già aviate. Non si genererebbe troppo traffico per via dei Task eseguiti in rapida successione e se abbinato ad una buona potenza di calcolo potrebbe essere un approccio concorrenziale. Cercavo una soluzione all'Overhead che si genera nei Microkernel in parole povere. Che Minix sia basilare non c'è dubbio.

Sull'automount non so molto invece...

P.s.
Bei disegnini !!!

P.P.S.
Un sistema operativo dovrebbe essere essenziale e modulare, come dico io Tabbabile come Chrome ...

sai che sta cosa di gestione overhead e "istruzioni gia avviate" non l'ho capita?
l'unico modo per limitare l'overhead è limitare il numero di parametri,l'unico caso in cui viene gestito è nella creazione di un thread o processo quando al posto che inviare n parametri in n messaggi viene inviato un solo messaggio contenente gli n parametri gia compilati.

Se intendi una migliore distribuzione del carico in ambienti multitasking li è solo un problema di algoritmo di skeduling del program manager,in linux è molto ottimizzato rispetto ad altre piattaforme:
gestisce i processi con un round robin a classi di priorita(la priorita piu bassa è quella con priorita maggiore,con round robin intendo che sono messi in coda e a ogni processo spetta tot ns per poi essere rimesso in fondo alla coda(detto moolto semplicemente))aumentando di priorita i processi che sono in attesa di i/o o che non usano troppa cpu,penalizzando i processi troppo cpu bound(solo se ci sono ovviamente altri processi che aspettano)o che richiedono troppa memoria.

Come si vede i processi vengono alzati di livello se stanno facendo i/o in piu la priorita è formata da

BASE+CPU_TIME+NICE

ove
BASE=priorita base
CPU_TIME=viene incrementata ogni tick e dimezzata ogni secondo,serve per penalizzare i programmi cpu bound che se ad alta priorita girerebbero solo loro(se guardate su windows se avete un programma che impazzisce e usa tutta la cpu è molto difficile riuscire a fare qualcosa)
NICE=quasi mai usato permette all'utente di decrementare la propria priorita,ovviamente nessuno è cosi masochista!


Comunque scusate se sto andando completamente in OT ma mi serve come ripasso!

[Vincent Vega]

Estto, non riuscivo a spiegarmi ... una migliore distribuzione del carico in ambienti multitasking !!!