cim vic jader CPU, tim pomalejsi - bhyve

[Dan Lukes]

> optimalizace odebiranim casti z GENERICu mi asi nestoji za ten cas,
> ktery pak muzu stravit resenim problemu, ktery nikdo jiny nepozoruje

Smyslem optimalizace tohoto druhu nemusi byt uspora mista na disku 
(mensi velikost kernelu jako souboru), pameti (mene kodu zabira mene 
mista v pamety) nebo vykonu (i ovladace nepritomnych zarizeni mohou 
provadet nejake akce).

Kapacita disku, pameti nebo vykon uz dneska asi nikoho moc nepali.

Jedna motivace ale zustava. Muj spoluzak rikaval "vic hlav, vic 
skopovyho". Pro programovy kod je to treba drobne upravit - "vic kodu, 
vic chyb".


On 8.5.2021 11:57, Miroslav Lachman wrote:
> Po upgrade na 12.2 a reinstalaci vsech portu (VirtualBox stale ve verzi 
> 5.2.44) doslo pri restartu VirtualBoxu na kernel panic a okamzity reboot 
> systemu. Neco takoveho jsem uz dlouho nevidel

Ja ano, Naposledy, pri upgrade VirtualBoxu, kdyz se po restartu kernelu 
nahral VB-kmid z predchozi verze.

Obecne je VB hodne upgrade-citlivy. Je treba davat bacha aby cmd-line 
programy verzi souhlasili s kernel modulem a ten sam samozrejme musi byt 
urceny pro tu verzi kernelu na ktere je nahran.

Mimochodem, jestli se neco nezmenilo, tak "kernel memory space", tedy 
pamet, kterou ma k dispozici kernel, je pevne dana konfiguraci. Za 
utcitych okolnosti muze dojit k jejimu vycerpani - a to prakticky vzdy 
vede k PANICu. No a to nastane tim mene pravdepodobne cim mene je 
potencialnich komzumentu (i kod sam take zabira misto). Takze vlastne 
neni tak uplne vzdycky pravda, ze "pameti mame dneska uz vzdycky dost".

> ve 12.2 oproti 11.4 zmenilo

Pro existujici filesystem by se nemelo zmenit nic. Nevim ale jestli nove 
filesystemy nejsou vytvarene v nejakem jinem nastaveni (softupdates, 
journal, ...).

> filesystem to odnesl dost osklive (stovky poskozenych / ztraceny [lost+found] souboru)

Na to ve skutecnosti staci pomerne mala zavada - poskozeny zaznam 
adresare, ve kterem vsechny tyhle soubory byly.

> K dalsimu testovani jsem se ale nedostal, protoze Guru Meditation:
> VBox.log.1:03:13:11.811807 Changing the VM state from 'RUNNING' to 'GURU_MEDITATION'

Tohle uz je pozde. "Guru Meditation" je posledni krok, kdyz VB uz proste 
nedokaze vyresit nejaky problem. Zajimavejsi tak nejspis sou radky LOGu, 
ktere tomu predchazely. Zrejme ale jde o nejaky problem s pameti 
(VERR_NO_MEMORY), coz jsi ale poznal sam.

> S 6.1.22 se okamzite vratil syndrom okamzite paniky. Jakmile se spusti libovolny jeden virtual, tak  to shodi cely server a ja pak opravuju rucne FS.

Prilis mnoho neznamych. Tohle klidn emuze byt systematicka chyba metody, 
kterou upgradujes - i po tomto upgrade se k some dostaly komponenty, 
ktere k sobe verzove nepatrily. No a nebo to bylo neco jineho ...

> Z celeho toho laborovani mam ale z kombinace FreeBSD a VirtualBox velmi  horkou pachut v puse 

To je legitimni situace, ktera patrne nema jineho reseni nez vymenit 
virtualizacni engine. Protoze i kdybychom rpisli na pricinu problemu a 
io kdyby se ukazalo, ze je to cely jen nejaka trivialni chyba na tvoji 
strane, tvoje duvera se tim nevrati.

> Co si ale nedokazu moc vysvetlit je to, proc na testovacim serveru je to 
> ve stejne konfiguraci FreeBSD 12.2 a VirtualBox 6.1.18 porad pomale v 
> tom pfctl testu, kdyz na produkcnim se to zlepsilo do ocekavanych norem. 
> Zarovn proc na testovacim serveru nedoslo k zadnym padum systemu a na 
> produkcnim ano... Kdyz sjou oba stroje Intel Xeon z podobne doby, oba s 
> UFS, oba s GENERIC kernelem atd. Vsechny aktualizace tma probihaji 
> stejnym zpusobem ze stejneho privatniho repozitare.

Jak uz jsme rikal, prilis mnoho neznamych ;-)

Dan