2002 óta, amikor a kernel ACPI-támogatással bővült, egy felesleges várakozási - „dummy wait” művelet került be a kernelbe. Történt ez mindazért, mert akkoriban néhány chipkészletnél az STPCLK# nem volt időben érvényesítve a kernelben az üresjárat során. A dummy I/O olvasás késlelteti a további utasításfeldolgozást, amíg a CPU teljesen le nem áll. Az AMD egyik mérnöke azonban nemrégiben észrevette, hogy ezt a viselkedést a modern AMD Zen 3 hardvereken is alkalmazzák, és megállapította, hogy ez teljesítményproblémákhoz vezethet az terhelt és üresjárati fázisok között gyorsan váltó munkaterheléseknél, és különösen a nagyobb magszámú rendszerek, például a Ryzen Threadripper és EPYC platformok esetében.
K Prateek Nayak, az AMD mérnöke, kimutatta, hogy a hibás megoldása milyen jelentős hatással lehet a teljesítményre a modern hardverekre az AMD rendszereken. Az Intel CPU-k eközben nem használják ezt a kódutat a modern hardverekhez, így nem érinti őket ez a teljesítményvesztés. Az adott tesztben a minimum adatátviteli értékek 1390.52 százalékkal növekedtek és az átlagos adatátvitel is 50.85 százalékkal emelkedett.
Eredetileg az AMD egy javítást végzett itt, majd Dave Hansen, az Intel mérnöke tisztította és egyszerűsítette ezt a kódot. Ez utóbbi javítás egyszerűen nem alkalmazza ezt a "dummy wait" megoldást, kivéve a régebbi (Nehalem előtti) Intel rendszereket. Mostantól tehát az AMD rendszerek is kihagyják ezt a műveletet, amely a modern rendszereken ronthatja a teljesítményt. Mivel ez főként az leterhelt és az üresjárati állapotok között gyakran váltó munkaterhelésekre van hatással, valamint a nagyobb magszámú rendszereknél jobban észrevehető, az AMD EPYC szerver teljesítménye ezzel a javítással meglehetősen érdekes lehet, különösen a webszerver / adatbázis-munkaterhelések és más típusú gyors tesztek esetében.
„A Zen mikroarchitektúrán alapuló processzorok támogatják az IOPORT-alapú mélyebb C-állapotokat. Az üresjárati meghajtó az acpi_gbl_FADT.xpm_timer_block.address.address értékét olvassa. az IOPORT-alapú C-állapot kilépési útvonalában, amely egy "Dummy wait op", és az ACPI Linuxba történő, Andy Grover által 2002. március 14-i bevezetése óta létezik. óta létezik. A dummy művelet feletti megjegyzést Andreas Mohr adta hozzá 2006-ban:
Ahogy a mérnök fogalmazott: „Dummy wait op - must do something useless after P_LVL2 read because chipsets cannot guarantee that STPCLK# signalgets asserted in time to freeze execution properly.”, azaz „Dummy wait op - a P_LVL2 olvasás után valami haszontalant kell tennie, mert a lapkakészletek nem tudják garantálni, hogy az STPCLK# jel időben érvényesüljön a végrehajtás megfelelő befagyasztásához.”
Bizonyos munkaterhelések mintavétele az IBS-szel AMD Zen3 rendszeren azonban azt mutatja, hogy hogy jelentős mennyiségű időt tölt el a dummy op, ami tévesen C-állapotú rezidensként kerül elszámolásra. A nagy C-State rezidenciaérték a cpuidle governor-t arra késztetheti, hogy mélyebb C-állapotot javasoljon a következő üresjáratok során, ami egy ördögi kört indít el, ami a teljesítmény romlásához vezet olyan munkaterheléseknél, amelyek gyorsan váltanak az elfoglalt és az üresjárati fázisok között. Az egyik ilyen munkaterhelés a tbench, ahol hatalmas teljesítménycsökkenés következhet be. bizonyos futtatások során megfigyelhető. Az alábbiakban néhány statisztikai adatot mutatunk be a tbench 128 klienssel történő futtatásával, egy kétfoglalatos (2 x 64C/128T) Zen3 processzoron. rendszeren az alapszintű rendszermaggal, az alapszintű rendszermag C2-t tartva letiltva, és az alapszintű kernel a javítás alkalmazásával, a C2-t engedélyezve tartva:
Kernel : baseline baseline + C2 disabled baseline + patch Min (MB/s) : 2215.06 33072.10 (+1393.05%) 33016.10 (+1390.52%) Max (MB/s) : 32938.80 34399.10 34774.50 Median (MB/s) : 32191.80 33476.60 33805.70 AMean (MB/s) : 22448.55 33649.27 (+49.89%) 33865.43 (+50.85%) AMean Stddev : 17526.70 680.14 880.72 AMean CoefVar : 78.07% 2.02% 2.60%
Az adatok azt mutatják, hogy vannak olyan szélsőséges esetek, amelyek hatalmas visszalépéseket okozhatnak. a tbench esetében. A rossz futások profilozása az IBS-szel jelentős az acpi_idle_do_entry módszerrel töltött idő jelentős részét:
Overhead Command Shared Object Symbol 74.76% swapper [kernel.kallsyms] [k] acpi_idle_do_entry 0.71% tbench [kernel.kallsyms] [k] update_sd_lb_stats.constprop.0 0.69% tbench_srv [kernel.kallsyms] [k] update_sd_lb_stats.constprop.0 0.49% swapper [kernel.kallsyms] [k] psi_group_change
