Názory k článku
BFQ plánovač vhodný na desktop

tak ten plánovač není jen pro NVMe, ale pro disky obecně

testováno je to na NVMe, ale vhodné to je pro desktop, kde záleží na latenci
mimochodem Zprávička

U startu KDE nebo různých IDE je to celkem jedno, ale např. LibreOffice mi neběží pořád, ale občas v něm potřebuji něco otevřít.

Další důležitá (resp. ještě důležitější) vlastnost je, jak se systém chová při zátěži -- jde o to, aby nějaké operace na pozadí nezpomalovaly interaktivní práci.

Me to treba zajima, a kdyz jsem se kompiloval a nastavoval s vanila kernelem, volil jsem na desktopu prave tenhle planovac. Dneska su na to jednak uz moc liny a jednak jde technika rychle dopredu a s ni i vykon zarizeni, ze uz mi to prijde vicemene skoro jedno (nebo mi to za to proste nestoji).

Nejste. Taky tuhle honbu za dalšími desetinami vteřiny nechápu. Kvalitní plánovač má samozřejmě smysl, jak tu i další píši, při zátěži, ale proč tolik lidí řeší jestli jim to či ono naběhne za vteřinu nebo za dvě je mi záhadou.

Nebo možná spíš bohužel není. Je to taková klasická starost prvního světa a ukázka, jak dnes lidé naprosto nejsou schopni rozlišovat chtěné a nutné.

Tady jde o cca 10-násobné zlepšení, takže počítejte jednu sekundu versus deset. Pomalý start aplikací a pomalá reakce systému na okamžité nároky aplikací (například větší alokace paměti) jsou známou bolestí linuxového desktopu, a je dobře, že se s tím něco dělá.

1. Co to má společného s odezvou systému na větší alokaci paměti? Vůbec nic. Vždyť je to jako kdybyste napsal "Linux má fakt dobrý i/o scheduler", a někdo odpověděl "nemá, mě nejde přečíst JPEG obrázek z SD karty". Prostě to spolu nemá nic společného.

2. Ten hotfix je k dispozici i pro Win7 SP1:
https://support.microsoft.com/en-us/help/2670667/handle-leak-occurs-in-the-audiodg-exe-process-in-windows-7-or-in-windo

3. Daleko spíš ale jde o resource leak v nějaké aplikaci. Aplikace si otevře handle na audio device, a nezavře ho po sobě. V druhém linku vidíte, že u někoho za tím problémem byl Steam. Když danou aplikaci ukončíte, tak by se měla paměť uvolnit. Pokud jde o resource leak v nějakém servisu nebo driveru (vizte níže), tak ukončení aplikace možná nepomůže.
https://steamcommunity.com/groups/SteamClientBeta/discussions/0/2381701715730728002/

Může také jít o resource leak v Sound Enhancements, které si můžete nastavit ve vlastnostech zvuku. Například APO Equalizer (který se ovšem zapíná/vypíná jinde) v nějaké verzi podle všeho měl problém s uvolňováním zařízení, přes které přehrával.
https://sourceforge.net/p/equalizerapo/discussion/general/thread/4a68ed36/
https://sourceforge.net/p/equalizerapo/discussion/general/thread/0b82e472/

A samozřejmě to může být problém driveru, resp. toho klubka kódu, které se instaluje se samotným driverem. Ujistěte se, že máte poslední WHQL driver pro příslušný HW. Při troše štěstí by vám to měl stáhnout Device Manager když vyhledáte driver. Problém nastane, když máte nějakou zvukovku bez certifikace WHQL; bohužel takové bývaly občas i na základních deskách. Výrobci HW jsou někdy při psaní driverů neskutečná prasata. Každopádně pokud budete tahat cokoliv od výrobce HW, zvážil bych stáhnut "driver package", rozbalil ho, odinstaloval současný driver, a nainstaloval jen vlastní nový driver (přes .inf file), bez toho cripplewaru, který výrobci často přikládají.

4. Pokud se jedná o resource leak, můžete to vidět v Task Manageru, když se podíváte na počet handles. Můžete si také zobrazit počet handles u jednotlivých procesů, dají se tam vybrat sloupce. Víc detailů se dá zjistit v Process Exploreru (ze SysInternals Suite). Pokud zjistíte kde handles leakují, tak můžete použít AppVerifier a debugger. Zjistíte tak místo v kódu, odkud se ty handles otevíraly. Nicméně nemá smysl se do toho hrabat tímto způsobem, dokud minimálně neprovedete update driveru, nezakážete Sound Enhancements a neodinstalujete případné doplňky které sedí mezi aplikací a zvukovou kartou. Asi nechcete strávit pár hodin času jen zjišťováním toho, že opravdu musíte strávit 5 minut aktualizací driveru zvukové karty :)
https://blogs.technet.microsoft.com/yongrhee/2011/12/19/how-to-troubleshoot-a-handle-leak/

Mňa startup time aplikácii zaujíma, ale keďže môj NVMe SSD číta podľa papierov 3100MB/s (reálne 2400MB/s) a vykoná niekoľko stotisíc IO/s, vúbec som to neriešil. Každá appka naštartuje hneď (do sekundy), gimp, LO, iba výnimočne štart brzdí výkon procesora Amd Ryzen 2700, napríklad NetBeans štartuje 2-3 sekundy.

Skromná otázka bez toho, abych chtěl nějak rýt, ale ze studijních důvodů: proč vás to zajímá? Jaký to pro vás má praktický (čímž myslím skutečně reálný, nikoliv pocitový) přínos?

Realny prinos je to, ze spustis a delas. Vic nez nekolikavterinovy prostoj (delsi buildy...) laka k tomu zacit delat neco jineho, typicky ne tak uzitecneho.

Když se podíváš do popisů grafů, tak zjistíš, že to spouštění terminálu probíhalo s dalším I/O na pozadí.