Viceprocesoru a FreeBSD

Divacky Roman xdivac02 at stud.fit.vutbr.cz
Fri May 5 09:46:18 CEST 2006


On Thu, May 04, 2006 at 09:53:25AM +0200, Dan Lukes wrote:
> Divacky Roman napsal/wrote, On 05/04/06 09:32:
> >> Muzes napsat v cem,prosim?
> > 
> > mam na mysli algoritmicka/designova omezeni v jadre
> 
> 	Mernou nezanedbatelnou se na tom podili stale nedokonceny ULE 
> scheduler. A puvodni 4BSD scheduler opravdu neni na viceprocesorove 
> masiny prilis dobre navrzen.
 
v cem je nedokonceny? mne prijde naprosto dokonceny :)
 
> 	Dale je zde stale jeste neodstraneny "giant lock" (ovsem jak dalece to 
> skutecne brzdi zalezi na tom, co stroj dela )
 
nemyslim ze je problem v Giantu.. dnes uz ne... tedka nekdo posilal mutex profiling 
a contestace Giantu byla malinkata - horsi jsou jine mutexy... presne si to
nepamatuju ale vim ze nekde v unix socketech je mutex ktery dost zdrzuje.. atp.

problem je v tom ze kdyz se predelavalo jadro na SMP tak se to vetsinou delalo
na 2x takze mame treba subsystemy ktere chrani jediny mutex a naopak subsystemy
ktere jsou predimenzovane a kazdou blbost tam chrani jeden mutex....

chce to kapku zoptimalizovat jeste... a to nemluvim o algoritmickych omezenich
- treba ted mame v 7.x novy malloc ktery je delany s podporou SMP a je toho vic
co je potreba upravit
 
> 	Zvlastni kategorie je HTT, kdy pridanim virtualniho procesoru (tedy 
> zapnutim HTT) celkovy vykon muze poklesnout (a vetsinou to udela).

no... ja si spis myslim ze to o HTT je dneska spis nezname... driv byla pravda
ze to skodilo vykonu ale uz to hafo dlouho nikdo nemeril - takze spravna
odpoved je asi to ze nikdo nezna vliv HTT na vykon



More information about the Users-l mailing list