@willliu Tried this on my machine with and without -lgompand I do get expected value for logical cpus

➜  /tmp go run main.go
number of current logic cpus:  24
➜  /tmp go version
go version go1.16.6 linux/amd64

My environment info

➜  /tmp uname -a
Linux turing 5.12.8-051208-generic #202105281232 SMP Fri May 28 12:35:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
➜  /tmp gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

@willliu Tried this on my machine with and without -lgompand I do get expected value for logical cpus

➜  /tmp go run main.go
number of current logic cpus:  24
➜  /tmp go version
go version go1.16.6 linux/amd64

My environment info

➜  /tmp uname -a
Linux turing 5.12.8-051208-generic #202105281232 SMP Fri May 28 12:35:52 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
➜  /tmp gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thank you for your reply, I later checked my bare metal, it is correct (same go, gcc, os). The original case is in cloud, so I suspect something with hypervisor is involved.

P.s. my machines are ARM64 instead of AMD64.

Go should be reading and parsing the value from https://linux.die.net/man/2/sched_getaffinity
Try checking the value from that, if that is wrong then I don't think there is something Go can do about it.

Go should be reading and parsing the value from https://linux.die.net/man/2/sched_getaffinity
Try checking the value from that, if that is wrong then I don't think there is something Go can do about it.

Thank you Alex, after check the source code, runtime.NumCPU traces back to func getproccount() int32 in file src/runtime/os_linux.go, which calls sched_getaffinity as you pointed out.

Now, I suspect that in some case cgo's linking with -lgomp makes sched_getaffinity less reliable to obtain number of CPUs.

btw, I tested on the error prone machine 1, with the following C++ code linked with openmp:

main.cpp

#include <iostream>
#include <string>
#include <omp.h>

using namespace std;

int main(){
    int numProcs = omp_get_num_procs();
    cout << "omp_get_num_procs() = " << numProcs << endl;
    return 0;
}

$ g++ main -fopenmp -lgomp -O3 -o main
$ ./main
$ omp_get_num_procs() = 16

It gives the correct number of logic cpus, so openmp seems work.

omp_get_num_procs is a completely different function, we need to know that sched_getaffinity in C/C++ works.
If it doesn't work in C/C++ then it is not specific to cgo.

omp_get_num_procs is a completely different function, we need to know that sched_getaffinity in C/C++ works.
If it doesn't work in C/C++ then it is not specific to cgo.

Alex, you pointed out the right direction, and I indeed found the source of error (and miracle).

main.c (adapted from stackoverflow.com/questions/10490756/how-to-use-sched-getaffinity-and-sched-setaffinity-in-linux-from-c)

#define _GNU_SOURCE
#include <assert.h>
#include <sched.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

void print_affinity() {
    cpu_set_t mask;
    long nproc, i;

    if (sched_getaffinity(0, sizeof(cpu_set_t), &mask) == -1) {
        perror("sched_getaffinity");
        assert(false);
    }
    nproc = sysconf(_SC_NPROCESSORS_ONLN);
    printf("sched_getaffinity = ");
    for (i = 0; i < nproc; i++) {
        printf("%d ", CPU_ISSET(i, &mask));
    }
    printf("\n");
}

int main(void) {
    cpu_set_t mask;

    print_affinity();
    return 0;
}

$gcc -o main main.c
$./main
$sched_getaffinity = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Now linked with -lgomp
$gcc -lgomp -o main main.c
$./main
$sched_getaffinity = 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

This agrees with golang's behavior previously, that runtime.NumCPU=1. Now the miracle is why linking -lgomp could change this on my virtual machine, does it hint that relaying on sched_getaffinity to get number of CPUs is less reliable? Could it happen for other virtual machine as well?

Thanks again Alex,

I would guess gomp is calling sched_setaffinity setting it to 1 or doing something weird.
You can try asking in gomp channels and see if they have any idea.

@n4j @AlexRouSg Thank you all, setting environment export OMP_PROC_BIND=false has solved this problem for now.

It looks like this has been resolved, and it looks like there is no change required to the Go source code. Closing.