Almost as an aside the article makes an interesting point: memory accesses can block. Presumably if it blocks because it's accessing a piece of hardware the operating system schedules another thread on that core ... but what if it blocks on a 'normal' memory access? Does it stall the core entirely? Can 'hyperthreading' briefly run another thread? Does out of order execution make it suddenly not a problem? Surely it doesn't go all the way down to the OS?

> what if it blocks on a 'normal' memory access?

If the CPU gotta wait for memory it's gotta wait, and so it just won't make progress. Though we typically say that the CPU has stalled.

How long depends on if it's found in one of the caches, they're progressively slower, or main memory.

All the fancy techniques like out of order execution, speculative execution and hyperthreads are mainly there to trigger memory reads as soon as possible to reduce how long it is stalled.

Some nice detailed SE answer here[1] with some details.

[1]: https://electronics.stackexchange.com/a/622912

> but what if it blocks on a 'normal' memory access? Does it stall the core entirely?

You won't be able to suspend a virtual thread, so that OS thread is going to be blocked no matter what. As far as kernel threads are concerned I think in practice when a page fault happens the kernel yields and lets another thread take over.

Hyperthreading is a feature where a single core can process two unrelated instruction streams (i.e. two threads) which is useful for software that executes few instructions per cycle.