2

I have 8 CPUs being implemented on ARM's big.LITTLE archiectuture. 0-3 as LITTLE CPUs and 4-7 as big CPUs.

I am trying to set the CPU affinity of an executing program using the following code:

// Set CPU affinity to multiple cores
void set_multiple_CPU_affinity(int *cpu_nums, size_t n, pid_t pid){
  cpu_set_t  mask;
  CPU_ZERO(&mask);

  for(int i = 0; i < n; i++)
  {
    CPU_SET(cpu_nums[i], &mask);
  }
  if (sched_setaffinity(pid, sizeof(mask), &mask) == -1) {
    printf("[!] Error in sched_setaffinity");
    perror("sched_setaffinity");
  }
  else {
    print_CPU_affinity(pid); // Code to print out CPU affinity set to
  }
}

int main(int argc, char** argv)
{
    int controlled_CPU_affinity[] = {4, 5, 6, 7};
    size_t n = sizeof(controlled_CPU_affinity) / sizeof(controlled_CPU_affinity[0]);
    set_multiple_CPU_affinity(controlled_CPU_affinity, n, 0);
    // More code here
}

My question is as follows:

When I go on to check using system trace (task monitor), I could see that the CPU affinity of program changes to CPU 3 instead regardless of setting up the affinity to certain CPUs. How can I force the affinity to be set to a core till the program finishes execution?

Richard Chambers
  • 16,643
  • 4
  • 81
  • 106
Somdip Dey
  • 3,346
  • 6
  • 28
  • 60
  • 8 CPUs being implemented on ARM's big.LITTLE archiectuture. 0-3 as LITTLE CPUs and 4-7 as big CPUs. – Somdip Dey Feb 15 '19 at 16:02
  • Can you actually force a CPU affinity to the big CPUs? It looks like that is what you are trying to do, to set the affinity to cores 4 - 7. See https://developer.qualcomm.com/blog/impact-big-core-little-core-architecture-application-development has this to say in "How much Control is Exposed", "Depending on the manufacturer, the platform may hide big and little core selection so that you don’t even need to think about it in your development, or they may provide varying degrees of control through APIs." – Richard Chambers Feb 15 '19 at 16:16
  • I am executing this program with highest privilege on the device and has root access. Actually, when the program starts executing it is set to one of the big CPUs but after a while it migrates to the LITTLE CPU, so I was hoping if there is any way to force the affinity to remain till the execution of the program is complete. I think the migration is automotaically performed by the Linux scheduler and nothing to do with the hardware in question. – Somdip Dey Feb 15 '19 at 16:20
  • My impression from the literature search I did, which admittedly was not thorough, is that setting the CPU affinity is more like a suggestion than an actual command. This suggestion may be honored or it may be ignored. With the ARM big.LITTLE architecture, my impression is that the scheduler is going to do what it wants in most cases. – Richard Chambers Feb 15 '19 at 16:22
  • LITTLE core is fine and affinity works perfectly but the issue happens with the big cores. My program might not be utilizing most of the core and since it consumes more energy to execute on big core the scheduler might be migrating the task onto LITTLE to save power. But I am not 100% sure because i can't think of a way to read scheduler's mind although I have the kernel code (used in the device) in front of me because scheduler uses different alogirthms based on different policies being used it is difficult to track every moving part of the prorgam. – Somdip Dey Feb 15 '19 at 16:26
  • I think that the problem is that the scheduler is overriding your affinity request and moving the process to a little core. Why do you want to override the scheduler? – Richard Chambers Feb 15 '19 at 16:31
  • Unfortunately, that is my job. Didn't mean it disrespectfully, but my task is to force a program to execute on a particular core and override the scheduler's decision being made. Anyhow, is there any way you are aware of that I can use to force the affinity on a CPU (or set of CPUs)? Thank you once again for your help in this. – Somdip Dey Feb 15 '19 at 16:33
  • [Linux support for ARM big.LITTLE (Feb-2012)](https://lwn.net/Articles/481055/) discusses some of the issues of CPU scheduling with big.LITTLE architecture. I suspect scheduler support will vary between Linux distros. What distro and version are you using? – Richard Chambers Feb 15 '19 at 16:42
  • Right now I am using Linux kernel 4.9 which implemnets the EAS and hence now has one scheduler governor: schedutil. SO we do not have to worry about which exact version I am using since everything is unified n EAS. But I am finding it hard to override some of the scheduler's decision and hence this problem is occuring. – Somdip Dey Feb 15 '19 at 16:48
  • 1
    This paper, [EAS Overview and Integration Guide from ARM](https://developer.arm.com/-/media/developer/developers/open-source/energy-aware-scheduling/eas_overview_and_integration_guide_r1p3.pdf) has a section on Tuning you may find helpful if you are building your own kernel. – Richard Chambers Feb 15 '19 at 17:11

0 Answers0