Which one will workload(usage) of the CPU-Core if there is a persistent cache-miss, will be 100%?

Question

That is, if the core processor most of the time waiting for data from RAM or cache-L3 with cache-miss, but the system is a real-time (real-time thread priority), and the thread is attached (affinity) to the core and works without switching thread/context, what kind of load(usage) CPU-Core should show on modern x86_64?

That is, CPU usage is displayed as decrease only when logged in Idle?

And if anyone knows, if the behavior is different in this case for other processors: ARM, Power[PC], Sparc?

Clarification: shows CPU-usage in standard Task manager in OS-Windows

Answer 1

A hardware thread (logical core) that's stalled on a cache miss can't be doing anything else, so it still counts as busy for the purposes of task-managers / CPU time accounting / OS process scheduler time-slices / stuff like that.

This is true across all architectures.

Without hyperthreading, "hardware thread" / "logical core" are the same as a "physical core".

Morphcore / other on-the-fly changing between hyperthreading and a more powerful single core could make there be a difference between a thread that keeps many execution units busy, vs. a thread that is blocked on cache misses a lot of the time.

Answer 2

I don't get the link between the OS CPU usage statistics and the optimal use of the pipeline. I think they are uncorrelated as the OS doesn't measure the pipeline load.
I'm writing this in the hope that Peter Cordes can help me understand it better and as a continuation of the comments.

---

User programs relinquish control to OS very often: when they need input from user or when they are done with the signal/message. GUI program are basically just big loops and at each iteration control is given to the OS until the next message. When the OS has the control it schedules others threads/tasks and if not other actions are needed just enter the idle process (long time ago a tight loop, now a sleep state) until the next interrupt. This is the Idle Time.

Time spent on an ISR processing user input is considered idle time by any OS. An a cache miss there would be still considered idle time.

A heavy program takes more time to complete the work for a given message thereby returning control to OS say 2 times in a second instead of 20.
If the OS measures that in the last second, it got control for 20ms only then the CPU usage is (1000-20)/1000 = 98%.

This has nothing to do with the optimal use of the CPU architecture, as said stalls can occur in the OS code and still be part of the Idle time statistic. The CPU utilization at pipeline level is not what is measured and it is orthogonal to the OS statistics.

CPU usage is meant to be used by sysadmin, it is a measure of the load you put on a system, it is not the measure of how efficiently the assembly of a program was generated. Sysadmins can't help with that, but measuring how often the OS got the control back (without preempting) is a measure of how much load a program is putting on the system. And sysadmins can definitively do terminate heavy programs.