Why is an infinite loop sleeping mostly on an isolated core?

Question

I tried the following code to give all execution time by isolating CPU on Centos 8:

#include <inttypes.h>
#include <pthread.h>
#include <sched.h>

int main()
{
    volatile uint32_t i = 0;

    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(15, &cpuset);

    pthread_t thread = pthread_self();

    int status = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
    // ... error checking ..

    while (1) {
        i++;
    }

    return 0;
}

However, the output of top command shows that the 15th CPU is in sleeping state mostly as below

Tasks: 287 total,   2 running, 285 sleeping,   0 stopped,   0 zombie
...
%Cpu15 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
...

Also the time output shows me the application uses the CPU only half of its time. Who uses the other half?

time ./cpu_test.out 
^C
real    0m10.984s
user    0m5.494s
sys     0m0.000s

I'm using the following settings:

kernel-4.18.0-80.11.2.el8_0.x86_64
CentOS Linux release 8.0.1905

# cat /sys/devices/system/cpu/isolated
2-17

# cat /sys/devices/system/cpu/present
0-17

# cat /proc/cmdline 
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-80.11.2.el8_0.x86_64 root=/dev/mapper/cl-root ro crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet nosoftlockup mce=ignore_ce intel_idle.max_cstate=0 processor.max_cstate=0 nohz_full=2-17 iommu=off isolcpus=2-17 audit=0 idle=poll skew_tick=1

# gcc --version
gcc (GCC) 9.2.0

# lscpu 
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              18
On-line CPU(s) list: 0-17
Thread(s) per core:  1
Core(s) per socket:  18
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               85
Model name:          Intel(R) Xeon(R) Gold 6254 CPU @ 3.10GHz
Stepping:            7
CPU MHz:             3899.999
CPU max MHz:         4000.0000
CPU min MHz:         1200.0000
BogoMIPS:            6200.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            1024K
L3 cache:            25344K
NUMA node0 CPU(s):   0-17
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities

What should I do about this? I really appreciate the assistance. If you guys need any missing information, I will edit my question.

EDIT 1

After Maxim Egorushkin comment, the things keep getting weird. I used perf tool and the output is as below, but 16th CPU usage stably more than 99% if I run the process with perf. Without perf, still suffering to get all CPU cycles.

# perf stat -ddd ./cpu_test.out
^C./cpu_test.out: Interrupt

 Performance counter stats for './cpu_test.out':

  14535.018449      task-clock:u (msec)       #    1.000 CPUs utilized          
             0      context-switches:u        #    0.000 K/sec                  
             0      cpu-migrations:u          #    0.000 K/sec                  
            45      page-faults:u             #    0.003 K/sec                  
56,195,943,206      cycles:u                  #    3.866 GHz                      (69.22%)
40,703,654,800      instructions:u            #    0.72  insn per cycle           (76.92%)
10,177,448,394      branches:u                #  700.202 M/sec                    (76.93%)
         3,171      branch-misses:u           #    0.00% of all branches          (76.93%)
10,179,958,967      L1-dcache-loads:u         #  700.375 M/sec                    (76.93%)
         4,651      L1-dcache-load-misses:u   #    0.00% of all L1-dcache hits    (76.93%)
           760      LLC-loads:u               #    0.052 K/sec                    (76.93%)
            12      LLC-load-misses:u         #    1.58% of all LL-cache hits     (76.93%)
<not supported>     L1-icache-loads:u                                           
          5,274     L1-icache-load-misses:u                                       (76.93%)
10,178,790,717      dTLB-loads:u              #  700.294 M/sec                    (76.92%)
             0      dTLB-load-misses:u        #    0.00% of all dTLB cache hits   (61.53%)
             0      iTLB-loads:u              #    0.000 K/sec                    (61.53%)
             0      iTLB-load-misses:u        #    0.00% of all iTLB cache hits   (61.53%)
<not supported>     L1-dcache-prefetches:u                                      
<not supported>     L1-dcache-prefetch-misses:u                                   

  14.535710128 seconds time elapsed

  14.449669000 seconds user
   0.002993000 seconds sys

Terminology: CPU15 is not the 15**th** CPU. It's the 16th because CPU0 is the first. — Peter Cordes, Jan 02 '20 at 15:16
Have you tried using `taskset -c 15 ./infloop` instead of having the process try to *migrate* itself to an isolated CPU after starting normally? Is the `100.0 id` core CPU15 taken while your process is running? Does it run / sleep in large chunks, like multiple seconds of running when it does eventually run? — Peter Cordes, Jan 02 '20 at 15:18
@PeterCordes taskset -c 15 ./infloop has the same effect and CPU15 is %100 while my process is running. Also it runs / sleeps in multiple seconds, large chunks — avatli, Jan 02 '20 at 15:32
Are you sure the thread's state is **R**_unning_? It could be that it blocks in `pthread_setaffinity_np`. Run it with `perf stat -ddd` instead of `time`. — Maxim Egorushkin, Jan 02 '20 at 17:52
@Maxim Egorushkin, it's state is running, the function returns with success. — avatli, Jan 02 '20 at 18:17
The above code is doing nothing, has no side effects in the loop, so what should the cpu do? Typically Have you checked with a debugger that you really have a loop and iteration in it? — Klaus, Jan 03 '20 at 08:10
@Klaus, this code was written only to reveal the problem. Cpu usage is 100% in centos 7, but centos 8 have a problem for the same code. Since volatile usage, there is a loop.. — avatli, Jan 03 '20 at 08:32
`time` shows 10 seconds total run-time with 5 seconds spent in the kernel. `perf` shows 14 seconds total run-time with 0 seconds in the kernel. Are these times from the very same executable? — Maxim Egorushkin, Jan 10 '20 at 12:01
@Maxim Egorushkin, yes.. As I edited, that's weird, but these times are from the same executable.. — avatli, Jan 11 '20 at 18:02

Why is an infinite loop sleeping mostly on an isolated core?

0 Answers0