How can I stop Ubuntu 20.04 from restricting my cpu space?

After installation of Ubuntu 20.04 everything was working well. However, after installing and using some applications (Matlab and Matlab/Dynare) Ubuntu seems to limit my cpu usage. I use openMP and a code that used to achieve 100% cpu use, but now it is much slower, and top shows the following: Output from top My processor has in total 32 cores with 64 threads. This code uses all the threads, and before it used to give me 100% cpu use. However,now total CPU usage is only about 18.9%. Note also that the main job is using almost 6400% cpu=64*100. The code now is very slow, compared to before. The following is what htop shows: Output from htop The threads are just doing independent calculations with no interaction (only put everything together at the end). In the past I had the same problem, and I solved it by reinstalling Ubuntu. Is there a way to solve the problem without reinstalling Ubuntu? In C++ I use a very simple loop with no interactions among threads (completely parallel):

// nproc is the number of threads to be used
// NIT is the total number of random draws to be obtained
// NITper is the number of random draws per thread, 
// NIT= nproc*NITper
arma::vec keepn=arma::zeros(NIT,1); // vector to keep the random draws
// Ydep is a matrix of data, it is to be read (but not modified) by threads. In reality I have more of these, but this is a simplified version. 
 
  omp_set_num_threads(nproc);  
#pragma omp parallel for schedule(static) 
  for (int ii=0; ii<=nproc-1; ii++){
   arma::vec Lkeepn=arma::zeros(NITper,1); 
         Gibbs_Inte(Ydep, Lkeepn, NITper);  
// Ask thread ii to obtain NITper random values, which are stored in Lkeepn
int l1=ii*NITper; 
int l2=(ii+1)*NITper-1; 
keepn.rows(l1,l2)=Lkeepn;  // write random draws in keepn
}

I checked the spec file of gcc and it is the same as after a fresh installation of ubuntu, so the problem is not there. Is it possible that some application changed system wide setting that restricts my cpu usage? How can I solve the problem?

If I do "strace -p PID" I get as follows:

sched_yield()                           = 0
futex(0x7fa75e2e6a10, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7fa75e2e6a10, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e5c80, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x7fa75e2e5c80, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e6d90, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fa75e2e7010, FUTEX_WAKE_PRIVATE, 1) = 0
sched_yield()                           = 0
futex(0x7fa75e2e6d90, FUTEX_WAKE_PRIVATE, 1) = 0
sched_yield()                           = 0

I have tried putting the shared variables that are only read by threads as firsprivate, but the problem remained.


The problem is that Matlab or/and Matlab/Dynare installs OpenBlas, and in Ubuntu 20.04 it has a bug, which has been reported elsewhere: https://github.com/xianyi/OpenBLAS/issues/2642

The solution is to uninstall OpenBlas. The following worked for me:

sudo apt-get remove libopenblas0
sudo apt-get remove libopenblas0-pthread

The code slowed when operating with matrices. OpenBlas was causing the threads to conflict with each other. Before removing OpenBlas I tried OPENBLAS_NUM_THREADS=1, but it didn't solve the performance issue. After removing OpenBlas my computations are as fast as they used to be (much much faster than using OpenBlas).