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