Viceprocesoru a FreeBSD

[Divacky Roman]

On Fri, May 05, 2006 at 10:46:37AM +0200, Dan Lukes wrote:
> Divacky Roman napsal/wrote, On 05/05/06 09:46:
> >> Divacky Roman napsal/wrote, On 05/04/06 09:32:
> >> 	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 :)
> 
> 	Ten nazor ti neberu, ale mozna s nim budes trochu osamoceny. Z nejakeho 
> duvodu onen novy dokonceny scheduler neni defaultne v systemu zapnuty, a 
> pokud ja mel moznost sledovat diskuse okolo toho, tak je to proto, z 
> eneni dostatecne stabilni.
 
pokud vim tak vsechny problemy s ULE byly vyreseny a ted je tento naprosto
stabilni jak pro UP tak pro SMP... ano, driv mel ULE problemy (ovsem s
nestabilitou, ne s tim ze by mu neco chybelo - tak aspon chapu pojem
nedokonceny) ale ted je to OK

ja vim ze dane nemas rad nove veci ale ULE je doopravdy v poradku (aspon tedy
neni momentalne znamy zadny problem s nim) - naopak, 4BSD je momentalne broken
a ma problemy (byt jak to vypada tak jen vykonove ale i tak)

a proc neni ULE defaultne zaply? protoze se na to zapomnelo - oficialni
politika je takova ze ULE mel byt defaultne zaply jen co vyjde 6.0R a pak se na
to zapomnelo... (viz commit messages)

navic - na ULE aktivne lide pracuji (jeff roberson na tu sice kasle ale jsou
jini) zatimco na 4BSD nikdo

ale mne je to jedno - at si kazdy pouziva co chce a jak chce.. akorat mi trosku
vadi ze dan tady siri neco co dle meho nejlepsiho presvedceni a znalosti proste
neni pravda ;(

> 	Ano v tom bychom se patrne neshodli. Problem ztraty vykonu s HTT nepada 
> az tak na vrub OS, ale predevsim na HW samotny - a nemam dojem, ze by 
> nove procesory mely HTT udelane nejak uplne jinak, nez ty drivejsi (pro 
> jistotu - dual-core != HTT).
 
myslim ze overhead v OS ktery je pro HT potreba je pricinou te "pomalosti",
bylo by urcite zajimave zmerit treba 2xCPU se zaplym HTT a vyplym (tj. na
systemu kde ten overhead je tak jako tak)
 
> 	Detaily viz napriklad clanek, na ktery tu nekdo posilal odkaz, nebo 
> staci infomrace oo tom, jak je HTT realne v procesoru implementovano a 
> prosty selsky rozum.
 
dane promin ale tohle je smesne - tuny nejlepsich hw designeru sveta (a verim
ze intel asi nezamestnava zadna Bcka) neco vymysli a "selsky rozum" to popre...
to je blbost
 
> 	Nevidim tedy zadny zasadni duvod, proc by zavery z drive namerenych 
> hodnoty mely byt novejsimi merenimi vyvraceny.

proste protoze se fbsd vyviji - drivejsi zpomaleni pri HTT mohla byt zpusobena
necim co je ted odstranene... co kdyz se predtim chapal HTT jako plnohodnotny
scheduler a schedulovalo se podle toho a ted se chape HTT jako
neplnohodnotony-procesor a ma to vliv na vykon? fakt nechapu dane jaka mentalni
bariera ti brani videt to ze pokrok semtam prinasi i positivni veci

> 	Optimiste se tedy mohou utesovat, ze jejich prani, aby se situace 
> zmenila se jim, i kdyz nevedi proc a sami to nemerili, splnilo, my 
> realiste, s dovolenim, setrvame u obav, ze stav je stejne neuspokojivy, 
> jako byl drive - protoze nemame zadny rozumy duvod od techto obav upustit.

a pro jistotu zustaneme u dernych stitku pac ty magneticka zaznamova media 
jsou prece jen nevyzkousena a buhvi jak to s nima je... ach boze ;(