Newsgroup: it.comp.os.dibattiti
Titolo: Nuovo networking stack di Vista e curiosità sul "big kernel lock".

Salve a tutti!
Ho seguito oggi, con molto interesse, questa chiacchierata informale con il 
team che ha riscritto praticamente da zero il networking stack di Vista, 
stack che dovrebbe fare la sua comparsa integrale nella Beta 2.
http://channel9.msdn.com/showpost.aspx?postid=116349
Tra le varie cose interessanti, viene ricordato come (con il vecchio stack) 
quando 
microsoft.com
 subì l'attacco di Blaster una macchina quadriprocessore 
venne messa in ginocchio anche per il fatto che tutto il traffico di rete 
veniva processato da una sola delle quattro CPU, mentre le altre tre erano 
pressoché scariche. Una delle novità rilevanti del nuovo stack sarà proprio 
la possibilità di suddividere il traffico in stream elaborabili 
indipendentemente in parallelo da tutte le CPU a disposizione. Che è una 
buona cosa... Tuttavia sono rimasto stupito dal fatto che questa scalabilità 
fosse assente nel vecchio stack (anche se, nota la sua derivazione da BSD, 
tutto torna) e mi domando: come funzionano le cose negli altri sistemi 
operativi? Gli stack di Linux, di Solaris, di MacOSX soffrono o soffrivano 
fino a poco tempo fa delle stesse problematiche di scalabilità? E Windows 
Server 2003 SP1 come si comporta?
Un'altra curiosità. Nonostante i grandi miglioramenti nel passaggio dal 
kernel 2.4 al 2.6, Linux soffre ancora di problemi legati al cosiddetto "big 
kernel lock" su sistemi SMP. Mi piacerebbe sapere se questo è un problema 
specifico dell'architettura di Linux o se è qualcosa da cui nessun sistema 
che lavori in SMP può completamente salvarsi, a prescindere 
dall'architettura.
SALUTONI,
WindoM 

 dall'architettura.
Mi sono chiesto la stessa cosa un pò di tempo fa quando ho scoperto 
dell'esistenza di CONFIG_PREEMPT_BKL, ho dato un'occhaita al codice ma 
non ci capisco una mazza.
Sono curioso di sapere cosa fa...

 Sono curioso di sapere cosa fa...
http://kerneltrap.org/node/3843
Questo dovrebbe far chiarezza a te circa l'esistenza di quel parametro e 
dovrebbe rispondere in parte alla mia domanda. Chi ne sa di più ci illumini, 
anche perché resta da capire se il BKL sia (o, alla luce della patch di 
Molnar, sia stato?) un problema specifico di Linux o no.
SALUTONI,
WindoM 

 dall'architettura.
Il BKL esiste ancora e forse continuerà ad esistere per molto tempo.
La buona notizia è che ultimamente (ultimi 2.6.x) non copre più le
aree critiche del kernel.  In pratica è come se non ci fosse.
Inoltre è stata introdotta una patch di Ingo Molnar che in qualche modo
lo "rompe" sotto certe condizioni, ma non chiedermi particolari :)
Non ci sarebbe nessun impedimento teorico per l'eliminazione definitiva
del BKL, basterebbe sostituirlo con dei lock più specifici, il problema è
la chiamata ioctl(2) che di fatto è un multiplexer di chiamate ognuna
delle quali tocca aree diverse del kernel e il BKL è il modo più semplice
per gestire la concorrenza in questi casi.  Forse si potrebbe eliminarlo
ma dato che ioctl() non è nei "fast path" non ci sono molti incentivi a
farlo.
-- 
Lorenzo

Fabio Fioretti - WindoM wrote:

Il BKL non è un "problema" è solo un meccanismo :)
Si parte da un kernel non SMP e si dice: ok il kernel può
essere eseguito su uno qualsiasi dei processori presenti
a patto che prima di entrarvi acquisisca il lock.
Tutto funziona a meraviglia e con poco sforzo si trasforma
un kernel uniprocessore in un kernel SMP.
La scalabilità in userspace è perfetta, 100%.
Il problema la scalabilità del kernel per cui con il tempo
si tende a sostituire il BKL con lock più fini che coprono
aree più ristrette, consentendo un concorrenza maggiore.
Questa evoluzione è una cosa del tutto naturale.
Ogni kernel SMP prima o poi è passato atraverso la fase
di rottura del BKL in lock più piccoli, ci sono passati i *BSD
e indirettamente anche Solaris dato che discende da essi.
-- 
Lorenzo

 farlo.
Sei stato chiarissimo in entrambi i tuoi post; mi sfugge però questo 
concetto di "fast path": potresti approfondire?
SALUTONI,
WindoM 

 concetto di "fast path": potresti approfondire?
Un fast path è un pezzo di codice dove l'esecuzione procede secondo
una via preferenziale che in generale rappresenta il caso più comune.
Nel caso di ioctl intendevo dire che le applicazioni normali non la
invocano così tante volte da diventare un problema per le prestazioni.
O almeno così dovrebbe essere..
-- 
Lorenzo


The difference between stupidity and genius is that genius has its 
limits. (A. Einstein)