A dobre, mel jsem to jinak pojmenovat. [...] V userlandu pokud to aplikace umi, tak samozrejme bezi ve vice vlaknech, ale pokud potrebuje pristoupit do kernelu, tak muze vzdy jen v jednom vlaknu. [...]
Coz samozrejme muze ve velmi specifickych pripadech vykon ovlivnit.
No to je ale docela zasadni nedostatek, ne? Ne ze bych se v techhle low-level vecech vyznal, ale prijde mi to jako dost zasadni problem, kdyz mame dneska systemy s az desitkami jader...
Je to hlavni problem nizkeho vykonu OpenBSD?
P.S. FreeBSD se s timhle zacalo postupne vyrovnavat, pokud se nepletu, uz nekdy od verze 4.x...
Doporucuju tu prezentaci co jsem poslal, ono se to totiz da resit i jinak a OpenBSD se o to snazi. To neznamena, ze na zpusobu v jinych OS je neco spatne, ale jen proste jsou strasne slozite na implementaci a spravnost. Taky maloco tuhle vlastnost vyuzije. Desitky jader OpenBSD samozrejme vyuzit umi. To o cem mluvim je jeste vice low level. Pokud mas nekde po ruce OpenBSD na vice procesorove masine, tak pust make, X, firefox a dalsi veci, deleje toho vice najednou a uvidis, ze vyuziva pokud mozno rovnomerne vsechny jadra ze bezi nekolik veci najednou na vice jadrech. Taky moc aplikaci obecne na trhu neni moc psano pro vicevlaknove pouziti, neni tak lehke je prepsat.
Obecne nizsi vykon je zpusobeny spise implementaci silnejsiho sifrovani nez v jinych systemech na vice mistech a by default nez v jinych systemech. I s obycejnym HW nemas problem treba na 1Gb siti mit realne kolem 100MB/s prenos (teoreticke maximum je 125MB/s pokud dobre pocitam :-)), rychlost disku je taky v podstate stejna jako jinde i kdyz velke rozdily jsou samozrejme i v ramci filesystemu a tak USB s ffs ma uplne jinou rychlost nez USB s fat32 atd. Tohle jsou ale veci, ktere si clovek nevsimne obzvlaste pokud to nepouziva a pokud se k tomu dostane jen obcas, tak si nevsimne vubec. Leda tak u toho prenosu z USB s fat32, ale on to je i na Linuxu spiste jen takovy trik s vyuzitim cache. Pokud ma clovek ext4 a prenasi tak velke soubory, tak si staci vsimat jak dlouho jeste flashka blika jak strhana i pote co system davno oznamil, ze soubor byl preneseny. Existuji velmi specificke oblasti vyuziti kde vykon opravdu nebude dostacovat, ale tam se obecne malokdy pouziva cokoliv z open source.
Ano, FreeBSD se v te dobe pro neco rozhodlo a nebyla to uplne stastna volba, protoze rada 5.x, 7.x a jeste i 8.x tim byla dost postizena a az u 9.x to zacina prinaset vysledky. Jeden z duvodu proc vlastne vzniklo DragonFlyBSD (ne-li ten hlavni duvod) byl ten, ze Matthew Dillon a dalsi vyvojari nesouhlasili s navrhovanym resenim SMP a tak se trhli a udelali v podstate to same (hodne ted zjednodusuji) co je v Solaris. Jsou uz ted ve stavu, ze skoro cely kernel uz funguje vicevlaknove, ale taky s tim maji dost problemy a je v tom dost bugu prubezne nachazeno. Opravdu to neni jednoduche.
tady prvni dva body
http://www.dragonflybsd.org/features/#index1h2moc pekne video o tomtez
http://www.youtube.com/watch?v=c5E2pWTwxJEJe to dost i o tazka financich zdroju, protoze poradna implementace zabere hodne casu, hodne lidi a tim padem i hodne penez. Ani Linux doted neni vnitrne uplne giant lock free, ale to uz jsou fakt jen detaily a to ma pochopitelne uplne jinou podporu ze strany velkych firem nez *BSD.
Ohledne podpory vice CPU/jader (SMP) se treba OpenBSD vydavalo cestou sparc64 a SGI kde byl a je mnohem kvalitnejsi HW a navrh platformy nez je u i386/amd64 (jeden z duvodu proc tak pozde OpenBSD ziskalo podporu vic nez 4GB RAM byl nekvalitni HW na amd64 kde Intel/AMD a jejich prvotni IOMMU bylo otresne). Proto kdo to trochu sleduje se mohl divit, proc chvili bylo BIGMEM dostupne v OpenBSD kratce po vydani jedne verze, ale pak to zase zrusili a objevi se to znovu oficialne az ve verzi 5.0, ktera vyjde 1.11.2011.
http://www.openbsd.org/papers/asiabsdcon2010_smp_for_sgi.pdfhttp://www.openbsd.org/papers/asiabsdcon2010_smp_for_sgi_paper.pdf
514 Odpovědí
100681 Zhlédnutí