AMD Did NOT Disable Branch Prediction With A Zen Microcode Update

[phoronix]

Phoronix: AMD Did NOT Disable Branch Prediction With A Zen Microcode Update

With the plethora of software security updates coming out over the past few days in the wake of the Meltdown and Spectre disclosure, released by SUSE was a Family 17h "Zen" CPU microcode update that we have yet to see elsewhere... It claims to disables branch prediction, but I've confirmed with AMD that is not actually the case...

http://www.phoronix.com/scan.php?page=news_item&px=AMD-Branch-Prediction-Still

[davidbepo]

OF COURSE IT DOESNT, that would mean a 60+% performance hit for everything

[xylef]

There's this from Fedora, which i guess might be that same microcode update: https://bodhi.fedoraproject.org/upda...018-41af2a8d65

https://bodhi.fedoraproject.org/updates/FEDORA-2018-53f304b0d3

[gens]

Branch prediction per se is not the problem, from what i understand. Speculative execution is the problem. As in the cpu executes code of one branch, and if it turns out it's the wrong branch the cpu backtracks.

Branch prediction used to be just to load code in L1 code cache.

[xpris]

This same update rolling today for Linux Mageia 6x64 as kernel update 4.14.10

30 gru 2017, 13:00:00 tmb <tmb> 4.14.10-1.mga6

        + Revision: 1187428
        - update to 4.14.10
        - update conflicts on nvidia-current
        - ALSA: hda - Fix missing COEF init for ALC225/295/299
        - cpufreq: schedutil: Use idle_calls counter of the remote CPU
        - tracing: Remove extra zeroing out of the ring buffer page
        - tracing: Fix possible double free on failure of allocating trace buffer
        - tracing: Fix crash when it fails to alloc ring buffer
        - update to 4.14.9 final
        - replace e1000e link detection fix patch with final one merged upstream
        - KVM: Fix stack-out-of-bounds read in write_mmio (CVE-2017-17741)
        - update to 4.14.9-rc3
        - update WireGuard to 0.0.20171221
        - disable SPI_INTEL_SPI_PLATFORM as it can corrupt BIOS on atleast many Lenovo laptops
        - update to 4.14.5
[B]        - x86/microcode/AMD: Add support for fam17h microcode loading[/B]
        - fix e1000e link detection regression
        - update to 4.14.4
          * drop merged patches
        - add current -stable queue
        - iwlwifi: add new cards for 9260 and 22000 series
        - iwlwifi: mvm: flush queue before deleting ROC
        - iwlwifi: mvm: enable RX offloading with TKIP and WEP
        - iwlwifi: mvm: mark MIC stripped MPDUs
        - update to 4.14.3
          * drop merged patches
        - autofs: revert "autofs: take more care to not update last_used on path walk"
        - autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
        - exec: avoid RLIMIT_STACK races with prlimit()
        - disable staging vboxvideo for now
        - sync with cauldron kernel-4.14.2-1
        - update to 4.9.56
        - update to 4.9.55
        - update to 4.9.52
        - add current -stable queue
        - update to 4.9.51
        - update bfq to v8r12
        - bfq: Add extra checks related to entity scheduling
        - bfq: reset in_service_entity if it becomes idle
        - bfq: consider also in_service_entity to state whether an entity is active
        - bfq: improve and refactor throughput-boosting logic
        - ideapad-laptop: add several ideapad laptops to no_hw_rfkill_list
        - ideapad-laptop: add ideapad 320-15IKB to no_hw_rfkill_list (mga#21728)
        - enable CC_STACKPROTECTOR_STRONG
        - enable FANOTIFY_ACCESS_PERMISSIONS (mga#21498)
        - update to 4.9.50
        - update to 4.9.49
        - update to 4.9.43
        - update to 4.9.40
        - update to 4.9.39
        - add current -stable queue
        - drop ThinkPad X1 Carbon fan fix as it causes regressions for other hw
        - sync with cauldron kernel-4.9.38-1.mga7

[AsuMagic]

OF COURSE IT DOESNT, that would mean a 60+% performance hit for everything

+1, there's a reason why branch prediction failure have massive effects on performance

[todda7]

Excuse my ignorance on the subject, but why would disabling speculative branch execution cause less of a performance hit than disabling branch prediction? What's the purpose of predicting what branch to execute if not to prematurely executing it?

[newwen]

Branch prediction per se is not the problem, from what i understand. Speculative execution is the problem. As in the cpu executes code of one branch, and if it turns out it's the wrong branch the cpu backtracks.

Branch prediction used to be just to load code in L1 code cache.

Branch prediction has to execute speculatively to be useful, as the performance gain is obtained by keeping the pipeline full.

[rene]

this random firmware distribution must stop, all the vendors need to step up their game to properly provide it sorted with history on their websites, and best obviously in some verifiably, best open source way. Mysterious firmware changes are really not what we need and can depend on.

[gens]

Branch prediction has to execute speculatively to be useful, as the performance gain is obtained by keeping the pipeline full.

The biggest performance gain is from fetching the code into L1 (and/or whatever the internal instruction buffer is called), otherwise the stall would be much much bigger.
The instructions can still be decoded, that is the second part of the performance gain.
Third part is actually executing them.

Modern cpu's go: fetch -> decode -> execute -> maybe write back results.
The "fetch" part is potentially the heaviest.

EDIT:
Just to be clear, "branch prediction" is the mechanism that predicts whether a "branch" in code goes one way or the other.
Only the mechanism, nothing else.
(There's a paper on the algorithm used in most, if not all, cpus. I forgot what it's called and cba to find it, especially as nobody will read it.)