7

I ran the following Java code on a Linux server:

while (true) {
   int a = 1+2;
}

It caused one CPU core to reach 100% usage. I'm confused about this, because I learnt that CPUs deal with tasks by time splitting, meaning that the CPU will do one task in one time slot (CPU time range scheduler). If there are 10 time slots, the while true task should have at most use 10% CPU usage, because the other 90% would be assigned to other tasks. So why is it 100%?

Boann
  • 48,794
  • 16
  • 117
  • 146
Jack
  • 5,540
  • 13
  • 65
  • 113

2 Answers2

10

If your CPU usage is not at 100%, then the process can use as much as it wants (up to 100%), until other processes are requesting the use of the resource. The process scheduler attempts to maximize CPU usage, and never leave a process starved of CPU time if there are no other processes that need it.

So your while loop will use 100% of available idle CPU resources, and will only begin to use less when other CPU intensive processes are started up. (if you're using Linux/Unix, you could observe this with top by starting up your while loop, then starting another CPU intensive process and watch the % CPU drop for the process with the loop).

J. Taylor
  • 4,567
  • 3
  • 35
  • 55
  • Still a bit unclear. If we have tons of stalled cycles (fronted or backed) will it be treated as 100% cpu usage anyway? – Some Name Feb 08 '19 at 18:31
  • 1
    Unfortunately, stalled cycles are included in CPU % metric in `top` and many other tools (which consider %CPU to be the % of time CPU is not in idle cycles). So you'd have to use other tools like `perf` to measure what % of the CPU usage was due to actual instructions being processed vs. stalled cycles (waiting for memory, etc). See: http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html – J. Taylor Feb 08 '19 at 18:51
  • 1
    You might also find this thread interesting: [What are stalled-cycles-frontend and stalled-cycles-backend in 'perf stat' result?](https://stackoverflow.com/questions/22165299/what-are-stalled-cycles-frontend-and-stalled-cycles-backend-in-perf-stat-resul) – J. Taylor Feb 08 '19 at 18:52
  • 1
    CPU % has nothing to do with CPU cycles, it is just the length of the *actual* quanta of a process vs the allocated quanta. A process can yield in a lot of implicit ways, shortening its quanta. This measurement is an estimation only and it is far too high level to be compared with CPU cycles. It's possible to count cycles with the PMC at each scheduling beat, but i'd be a useless metric (sysadmins don't care for unoptimised software) what just wastes PM resources. Things may change (or be clearer) when the `umonitor` instn will be widely available (if it will). – Margaret Bloom Feb 09 '19 at 12:22
3

In a multitasking OS the CPU time is split between execution flows (processes, threads) - that's true. So what happens here - the loop is being executed until some point when clock interruption occurs which is used by OS to schedule next execution "piece" from other process or thread. But as soon as your code doesn't reach specific points (input/output or other system calls which can switch the process into the "waiting" state, such as waiting for a synchronization objects sleep operations, etc.) the process keeps being in the "running" state which tells scheduler to keep it in the execution queue and reschedule its execution at the first best opportunity. If there are some "competitive" processes which keep their "running" state for long period of time as well the CPU usage will be shared between your and all these processes, otherwise your process execution will rescheduled immediately which will cause continuous high CPU consumption anyway.

Dmytro Mukalov
  • 1,949
  • 1
  • 9
  • 14