Sometimes a micrcode update slows down your CPU

By: Travis Downs (, March 24, 2019 6:56 pm
Room: Moderated Discussions
A month ago I noticed an old test I had for a weird store performance issue had changed behavior on my machine: whereas before it was usually fast, but sometimes (unexpectedly) slow, now it was always slow.

I traced the change down Intel's most recent microcode update. Removing makes things almost always fast, and restoring it makes things almost always slow. Many more gory details in this blog post.

Although I can definitely say that the issue occurs when you deploy the new microcode, I can't say how direct the link is: the fact that it was sometimes slow before, means that it was always possible for this to occur and maybe the microcode slightly perturbed something more or less unrelated that through some chain of events means it almost always happens now. Or maybe the microcode really did change how store commit is handled, leading directly to this.

A small shred of evidence supporting the latter idea is that I noted some type of 64 KiB aliasing effect with the old microcode that also went away with the new microcode. Also, this microcode seems to mostly include switches for SSBD (speculative store bypass disable), which does implicate the store pipeline somewhat. Perhaps Intel even knew about SPOILER stuff when this microcode was being prepared, I'm not sure.

There are a long list of performance impacts from Meltdown and Spectre, and I'm not even sure if this is necessarily in that group (since after all we don't know the underlying cause) - but what makes it a bit different is that it slows down purely CPU bound code that doens't care about any of that stuff. Other impacts have been at context switch boundaries, at or after kernel transitions, inside the kernel itself, or with code that has to be Spectre-aware and do things like use retpolines or this-or-that-jamming or whatever. This isn't like that: it happens just when you do a lot of stores that miss. Things like populating certainly types or large, sparse data structures, or card marking in a JIT, etc would qualify.

Actual impact is likely to be relatively muted in practice because for most code you can slow down stores a lot without any impact because buffering hides their true latency (if a store can even be said to have "latency"). Still, if you find that "store bound" scenarios seem to have increased lately, e.g., increased counts for in '' - this is one possible cause.

The original RWT starts here. Thanks to Adrian for his recent helping testing on some other archs deep in that thread, and to other users who provided results back then.
 Next Post in Thread >
TopicPosted ByDate
Sometimes a micrcode update slows down your CPUTravis Downs2019/03/24 06:56 PM
  Sometimes a micrcode update slows down your CPUAnonymous Lurker2019/03/26 07:49 AM
    Sometimes a micrcode update slows down your CPUTravis Downs2019/03/26 09:48 AM
Reply to this Topic
Body: No Text
How do you spell green?