View Full Version : Kernel BSD e Linux
differenze fra il kernel bsd e quello di linux?
come è messo a multitasking? perchè linux fa un po' pena a riguardo... supporto hardware?
e (non c'entra con il kernel) come funzionano i pacchetti? stile debian o gentoo? sorgenti o binari?
grazie
cimi
#!/bin/sh
07-09-2005, 20:11
scusami come fai a dire che linux fa pena in quanto a multitasking?
scusami come fai a dire che linux fa pena in quanto a multitasking?
non mi pare sia molto meglio di windows... che non è affatto multitasking... fai partire un po' di apps contemporeaneamente e te ne rendi conto... anche far partire un mp3 e poi montare un cd... il sistema si blocca un attimo...
ha una buona gestione della ram e/o cache, cioè le apps già caricate vengono richiamate molto velocemente ma rimane il problema multitasking imho
supporto hardware?
e (non c'entra con il kernel) come funzionano i pacchetti? stile debian o gentoo? sorgenti o binari?
grazie
cimi
- supporto hardware?
imho scadente.
- come funzionano i pacchetti? stile debian o gentoo? sorgenti o binari?
sorgenti (stile porting gentoo) e binari (stile debian)
Cimi ma che fine avevi fatto?... pensavo t'avessero rapito :D
Cimi ma che fine avevi fatto?... pensavo t'avessero rapito :D
...abduction... no esami di maturità!
non mi pare sia molto meglio di windows... che non è affatto multitasking... fai partire un po' di apps contemporeaneamente e te ne rendi conto... anche far partire un mp3 e poi montare un cd... il sistema si blocca un attimo...
il problema che rimane è che se l'hd sta cercando una cosa non può prenderne un'altra.
che se si sta leggendo da un indirizzo non si può fare su un'altro....
morale: comprati 8 processori con 8 hd e 8 bridge (diaciamo 8 pc :D)e potrai anche comprimere 8 video contemporaneamente ;)
cmq, a parte gli scherzi se sei insoddisfatto delle prestazioni prova a giocare un pò con gli algoritmi di scheduling sugli hd in /sys/
non esiste quello migliore, viene impostato di default quello che statisticamente va meglio, magari non è fatto per l'uso che fai te del pc...
io sad esempio mi trovo bene con il deadline. l'anticipatory mi dà dei problemi di grossissima latenza negli accessi a hd sotto carichi elevati.
ciao!
Michele81
08-09-2005, 00:16
non mi pare sia molto meglio di windows... che non è affatto multitasking... fai partire un po' di apps contemporeaneamente e te ne rendi conto... anche far partire un mp3 e poi montare un cd... il sistema si blocca un attimo...
Nel topic in cui si parla di beos e Haiku, qualcuno (non ricordo chi) ha fatto questi esempi, mettendo in risalto il fatto che su questi ultimi questo non accade (se non ricordo male grazie alla particolare struttura del kernel/sistema)
SilverXXX
08-09-2005, 09:24
Tra i due kernel, la differenza è che quello dei BSD è un microkernel
ilsensine
08-09-2005, 09:56
come è messo a multitasking? perchè linux fa un po' pena a riguardo...
Già linux è uno dei sistemi meno scalabili del mondo :p
fai partire un po' di apps contemporeaneamente e te ne rendi conto...
Me ne rendo perfettamente conto ;)
anche far partire un mp3 e poi montare un cd... il sistema si blocca un attimo...
L'accesso a un cd blocca l'intero canale ide per un certo tempo. E' una limitazione hw abbastanza rognosa da gestire...
Puoi verificare facilmente se stai incappando in questo problema, copiando il file mp3 su un ramdisk ramfs (_non_ su tmpfs) e vedere se il problema scompare.
The Katta
08-09-2005, 11:09
Tra i due kernel, la differenza è che quello dei BSD è un microkernel
Bè, questa è proprio grossa eh :sofico:
wikipedia aiuta sempre
http://it.wikipedia.org/wiki/Kernel
jappilas
08-09-2005, 11:43
Nel topic in cui si parla di beos e Haiku, qualcuno (non ricordo chi) ha fatto questi esempi, mettendo in risalto il fatto che su questi ultimi questo non accade (se non ricordo male grazie alla particolare struttura del kernel/sistema)
il punto di BeOS (e quindi si presume di altri sistemi che ne vogliano imitare il comportamento) è il multithreading "pervasivo", quindi esteso a tutti i livelli che saranno tenuti a far apparire come effettivamente parallelo il modo di servire le richieste da parte di applicazioni, servizi (per quanto riguarda i "Kit", librerie userspace) o altri pezzi del kernel (per quanto riguarda l' implementazione dell' IO a basso livello), garantendo la coerenza transazionale e senza imporre "lock" a livello globale...
in linea di principio questo si attua applicando la mutua esclusione (semafori/spinlock/mutex) con una granularità il più fine possibile sulla singola risorsa logica contesa (ad es il file), e la serializzazione dei comandi verso il device fisico (volume su HDD magari ve n'è uno solo e accetta un comando per volta) in modo trasparente e all' ultimo stadio
BSD e Linux che io sappia sono ancora piagati da sottosistemi "sotto" un Lock globale, ridurre l' influenza del quale è sentito come una necessità in tutti i casi: nella serie 2.6 del kernel linux un approccio al problema sono stati i preemption points (che renderebbero pronte alle preemption alcune sezioni di codice critico, prima esclusivamente bloccanti), in FBSD 6 mi pare si stia cercando di rendere tutto il kernel "rientrante" e fuori dall' influenza del Giant lock, analogamente si stava cercando di fare per DragonflyBSD, che in più adotta un modello a thread "leggeri" interni al kernel
in tutti i casi migliorare questo aspetto è faticoso per via della concezione iniziale dei kernel legati dall' eredità Unix... in altri casi (Mach, QNX, BeOS, L4... ) kernel progettati ex novo facevano dell' assenza di global lock e della full preemptability punti di forza...
ilsensine
08-09-2005, 12:15
BSD e Linux che io sappia sono ancora piagati da sottosistemi "sotto" un Lock globale
Sotto linux non è più vero...
nb non confondere "regioni non sottostanti a preemption" a "lock globale". Ormai anche le poche regioni che usano l'unico vero lock globale rimasto (il Big Kernel Lock, BKL) possono essere soggette a preemption. Viceversa una regione non soggetta a preemption può non aver acquisito alcun lock globale.
Nel ramo -RT stanno rendendo "preemptible" praticamente tutto il kernel; l'ho testato qualche settimana fa sul mio vetusto Athlon 550 con HZ=250, e ho misurato una latenza massima di "wake up", sotto carico (intenso i/o e qualche cpu-hog come gnuchess) di ~39us.
Inoltre la preemption non va confusa con il throughput: potrei fare un s/o (mi sembra che alcuni BSD lo fanno, se non ho sentito male) che effettua il routing dei pacchetti di rete direttamente in contesto di hardirq: è una pessima scelta per ciò che concerne le latenze e il comportamento generale "realtime" del sistema, ma sicuramente sarebbe molto efficiente come router di rete.
il punto di BeOS (e quindi si presume di altri sistemi che ne vogliano imitare il comportamento) è il multithreading "pervasivo", quindi esteso a tutti i livelli che saranno tenuti a far apparire come effettivamente parallelo il modo di servire le richieste da parte di applicazioni, servizi (per quanto riguarda i "Kit", librerie userspace) o altri pezzi del kernel (per quanto riguarda l' implementazione dell' IO a basso livello), garantendo la coerenza transazionale e senza imporre "lock" a livello globale...
in linea di principio questo si attua applicando la mutua esclusione (semafori/spinlock/mutex) con una granularità il più fine possibile sulla singola risorsa logica contesa (ad es il file), e la serializzazione dei comandi verso il device fisico (volume su HDD magari ve n'è uno solo e accetta un comando per volta) in modo trasparente e all' ultimo stadio
BSD e Linux che io sappia sono ancora piagati da sottosistemi "sotto" un Lock globale, ridurre l' influenza del quale è sentito come una necessità in tutti i casi: nella serie 2.6 del kernel linux un approccio al problema sono stati i preemption points (che renderebbero pronte alle preemption alcune sezioni di codice critico, prima esclusivamente bloccanti), in FBSD 6 mi pare si stia cercando di rendere tutto il kernel "rientrante" e fuori dall' influenza del Giant lock, analogamente si stava cercando di fare per DragonflyBSD, che in più adotta un modello a thread "leggeri" interni al kernel
in tutti i casi migliorare questo aspetto è faticoso per via della concezione iniziale dei kernel legati dall' eredità Unix... in altri casi (Mach, QNX, BeOS, L4... ) kernel progettati ex novo facevano dell' assenza di global lock e della full preemptability punti di forza...
:ave:
Abbiate pietà di noi poveri utenti di Niubbo/Linux ed indicateci la via... ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.