[NOS] Kernel

[TheKaneB]

• 

nah, si sprecherebbe un intero core solo per il network... non mi piace più come idea, funziona in ambiti specifici ma mi rendo conto che per un dispositivo general-purpose l'architettura sarebbe inadeguata...

[AmigaCori]

• 

Quindi si chiude il cerchio e si ritorna al kernel ibrido perche' l'idea di Z80fan, cioe' il microkernel con una parte dei driver grafici nel kernel pare sempre un ibrido e richiederebbe dei driver speciali, cioe' divisi in "due"?, forse a quel punto ' piu' pratico avere un microkerel+driver grafici = ibrido.
E per il network?, sempre dentro il kernel dovrebbe andare, altrimenti perderebbe di senso avere i driver grafici dentro al kernel visto ch sia la grafica che il network generano molto traffico.

Quindi ibirdo che contenga solo di extra al minimo indispensabile driver grafici e networking.  :?:

[Z80Fan]

• 

Quindi ibirdo che contenga solo di extra al minimo indispensabile driver grafici e networking.  :?:

La possibilità che un pezzetto di driver (principalmente, come dicevo nella mia analisi, i gestori di interrupt e niente altro) stia in kernel-space deve poter essere disponibile a qualsiasi driver, non solo ai grafici e net. Ad esempio, al CERN potrebbero volere interfacciare un dispositivo complicatissimo che tassa i neutrini quando escono dal tunnel con il Gran Sasso ( ), e quindi genera una notevole quantità di traffico.

Quindi il kernel non fa distinzione tra "driver video e net" da "tutto il resto". Lui al boot (o al caricamento del driver) si carica nel suo kernel space questi moduletti e se li inizializza; poi che questi lavorino per una vga, una scheda di rete gigabit, un mulino a vento, un parchimetro per protoni, a lui non interessa.

[cdimauro]

• 

Concordo. Normalmente i driver staranno in user-space, poi se il vendor ritiene opportuno può metterli in kernel-space, o in entrambi.

Quindi si chiude il cerchio e si ritorna al kernel ibrido perche' l'idea di Z80fan, cioe' il microkernel con una parte dei driver grafici nel kernel pare sempre un ibrido e richiederebbe dei driver speciali, cioe' divisi in "due"?, forse a quel punto ' piu' pratico avere un microkerel+driver grafici = ibrido.

Che è quello che fa Windows da Vista in poi, se non ricordo male.

[TheKaneB]

• 

mettere in kernel space solamente le ISR è troppo poco :-)

Tempo fa studiando Symbian mi sono imbattuto in un'analisi sconcertante :-D
In pratica i primi cellulari con Symbian erano tutti dual core, con uno dei core dedicato esclusivamente alla gestione del GSM con un microkernel realtime separato. Il secondo core, più potente, faceva girare Symbian e tutte le applicazioni.

La separazione era necessaria perchè lo stack GSM richiede una cinquantina di thread schedulati su almeno 25 livelli diversi di priorità e scadenze strettissime che richiedono una schedulazione hard-realtime.
Quando Symbian fu reso real-time, si eliminò la necessità di avere un core dedicato per il GSM, tuttavia il codice dello stack GSM gira tutto in kernel space proprio per la criticità delle operazioni (sfutta dei kernel thread a priorità RT).

La struttura che dici tu basta per gestire dischi, porte I/O generiche, DMA, e roba relativamente lenta, ma è semplicemente inadeguata per stack di comunicazione di questo tipo. La sola ISR che piazza un po' di dati su un buffer e solleva un semaforo non basta, perchè l'overhead dei vari context switch e della vagonata di syscalls tra processi in user space (se mettiamo il driver network in user space) rende semplicemente inutilizzabile qualsiasi protocollo di comunicazione moderno. Generalmente le tolleranze accettabili da questi protocolli sono nell'ordine dei millisecondi.

Insomma, è il classico caso in cui la pratica fa a pugni con la teoria e bisogna mettere da parte l'estetica per far posto alle performances :-)

[TheKaneB]

• 

Giusto per farsi un'idea http://www.developer.nokia.com/Communit ... ck_on_EKA2

EDIT: più in basso nella stessa pagina, parla dei "Personality Layers" di EKA2 (il kernel di Symbian), che vengono usati per fare i porting degli stack di rete. Ad esempio se hai uno stack 3G basato su FreeRTOS, VxWorks o un OS realtime proprietario, si può fare una personality che emula le API di quell'OS e quindi fare girare lo stack 3G invariato sopra EKA2 / Symbian. Creare una personality, trattandosi di OS veramente piccoli e semplici, è roba che si fa in pochi mesi, mentre per fare da zero uno stack complesso come quello 3G o GSM o altro, si impiegano diversi anni.

[AmigaCori]

• 

Ho fatto caso che col vecchissimo P1i (usa UIQ) quando ascoltavo MP3, cascasse il mondo, non avevo nessunissimo problema o rallentamento.

Con l'X10, HW molto piu' potente, gli MP3 vengono micro interrotti ogni volta che si aggiorna la rete o se faccio qualcosa di pesante, non si arriva mai all'interruzione del player ma si hanno queste micro interruzioni, tipo 1/5 di secondo, se metto il telefono in modalita' volo sparisce il problema...almeno mi pare di capire visto che la cosa non accade sempre, pero', il vecchio UIQ andava meglio.  :geek:

EDIT
sai, il tuo link cade a ciccio perche' ieri sera mi stavo proprio chiedendo, ripensando alle micro interruzioni degli MP3, come si gestisse la rete ed il resto, per forza di cose la rete deve avere priorita' rispetto a tutto il resto in qualsiasi situazione...

[TheKaneB]

• 

UIQ è il nome della GUI sviluppata da Sony per Symbian. Il kernel di Symbian, come già detto, è un vero microkernel real time (come anche WindowsCE), mentre Android si basa su quella porcata di Linux, aggravata dalla presenza di una Java Virtual Machine subottimale, quale Dalvik.

[AmigaCori]

• 

Android non mi dispiace pero'...non e' un OS per PDA e quindi ecco che applicazioni banali come un MP3 player andavano meglio su Symbian che su Android...magari e' ottimo per un tablet, ma per un PDA ma...mi...boh  :?
E non venitemi a dire che e' colpa dell'HW perche' 1ghz mi pare piu' che sufficiente!  :evil:

[TheKaneB]

• 

La verità è che Android fa cagare, però è gratis e ci sono tanti programmi e iniziano a girarci un po' di soldi attorno :-D Ecco tutto!

[cdimauro]

• 

Soldi? Quali soldi? :lol:

[Z80Fan]

• 

Insomma, è il classico caso in cui la pratica fa a pugni con la teoria e bisogna mettere da parte l'estetica per far posto alle performances :-)

Ma infatti a me non da nessun problema, puoi metterci tutto quello che vuoi, io ho fatto un ragionamento su quello che conoscevo.
Una volta che il kernel può caricare roba, ci puoi caricare quello che vuoi; è cmq consigliabile mettere in user-space quelle cose non strettamente necessarie in modo da garantire il minor codice possibile che gira in kernel-mode.

[TheKaneB]

• 

Chiaramente stiamo parlando di un dettaglio implementativo che può avere vantaggi e svantaggi. In questi casi il mio approccio è quello di implementare entrambi, fare dei benchmark (profiling), e poi scegliere in base ai dati raccolti.

Dal punto di vista del safety non credo ci siano problemi, perchè non intendevo un unico spazio condiviso per tutti, ma alcune pagine condivise tra esattamente 2 processi. Quindi quando 2 processi vogliono scambiarsi messaggi verrebbero aperte due zone di memoria shared, una in sola lettura e una in sola scrittura, e questo previene anche le race conditions.

Farei passare questi messaggi comunque tramite una syscall, in modo tale da poter modificare in futuro l'implementazione.

Voglio mostrare la mia idea di IPC, così ci ragioniamo su e vediamo quali sono i punti deboli e se si possono risolvere:

- Processo A vuole comunicare con il processo B
- A invia una syscall open_channel(processoB)
- B riceve una notifica (nella sua message queue) e risponde con ack_channel(caller)
- il kernel setta due buffer di memoria condivisa e tramite MMU imposta i settaggi di lettura e scrittura in modo che A possa scrivere nel buffer AB e leggere dal buffer BA, mentre B possa scrivere nel buffer BA e leggere dal buffer AB.
- il Kernel risponde alla syscall restituendo offset e dimensioni del buffer condiviso
- A invia messaggi tramite send_message(processoB, message)
- il kernel, dato che "message" si trova già nel suo buffer, si limita a sollevare un semaforo, per svegliare B che è rimasto lockato sul suo semaforo nel buffer di lettura (il classico problema del produttore e consumatore)

In questo modo il kernel fornisce un meccanismo di comunicazione senza forzarne la policy. Infatti i processi possono decidere autonomamente il protocollo di comunicazione che ritengono adeguato, passandosi anche grosse quantità di dati.

Analogamente si possono fare messaggi broadcast impostando, sempre tramite MMU, una pagina in sola scrittura per il processo A, e in sola lettura per tutti i processi in ascolto.

La copia dei dati in realtà ci sarebbe comunque, perchè i processi A e B comunque se devono passare un Tot di messaggi grossi, li prepareranno in locale e poi li passeranno sul buffer in una sorta di streaming a pacchetti di dimensione fissa. Il guadagno sta nel fatto che la copia dei messaggi avviene in user space, mentre nel classico passaggio di messaggi lato kernel, la copia avviene da parte del kernel usando un buffer temporaneo in kernel space.
In teoria si dovrebbero risparmiare un paio di context switch per ogni messaggio e se i buffer sono allocati in modo opportuno, gli indirizzi virtuali potrebbero essere scelti in modo tale da sfruttare bene la cache della CPU (mantenendo fissi gli indirizzi dei buffer), che normalmente è la cosa che viene maggiormente penalizzata durante un context switch.

Comunque, ripeto, non ci metterei la mano sul fuoco riguardo l'efficienza di questo metodo, bisogna fare dei benchmark per capire se conviene o meno.
Così a naso mi sembra un sistema che può funzionare.

Voi che ne dite?

[clros]

• 

[...]
- il Kernel risponde alla syscall restituendo offset e dimensioni del buffer condiviso
[...]

In base a cosa il kernel decide la dimensione del buffer? Sarebbe opportuno fare decidere ai processi la dimensione da richiedere al Kernel e poi il kernel risponde con la dimensione del buffer che è riuscito ad allocare?

[clros]

• 

Questo metodo ha decisamente fallito nell'avere un buon rapporto performance/stabilità e andrebbe abolito. Nel safety e nel mission critical le risorse condivise nel concurrency sono distribuite by copy, che non è lento se queste sono decisamente piccole (in genere limitate solo all'aggiornamento degli state). In genere però la perdita di tempo nella copia viene recuperata dal fatto che l'accesso non è vincolato dal locking, quindi non ha molto senso parlare di performance in alcuni casi (dato che l'accesso è quasi sempre pessimizzato).

Davvero molto interessante...

Per esempio quei linguaggi che hanno il concurrency builtin forzano il passaggio by copy anche di grosse strutture (in genere passate by reference)

Posso chiederti di che linguaggi si tratta? Usandoli quindi non devo preoccuparmi della protezione esplicita dei dati condivisi tra processi o thread?