affinity of main thread is bound to current core

Philippe Gerum rpm at xenomai.org
Thu Aug 22 17:29:13 CEST 2019


On 8/22/19 5:16 PM, Lange Norbert via Xenomai wrote:
>> -----Original Message-----
>> From: Jan Kiszka <jan.kiszka at siemens.com>
>> Sent: Donnerstag, 22. August 2019 16:52
>> To: Lange Norbert <norbert.lange at andritz.com>; Xenomai
>> (xenomai at xenomai.org) <xenomai at xenomai.org>
>> Subject: Re: affinity of main thread is bound to current core
>>
>> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
>> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
>> ATTACHMENTS.
>>
>>
>> On 21.08.19 14:12, Lange Norbert via Xenomai wrote:
>>> Hello,
>>>
>>> I use Xenomai master on ipipe-core-4.19.60-x86-5.
>>> I start out with an affinity mask of 0xF, in the function cobalt_init_2,
>> pthread_setschedparam will get called, after the syscall
>> sc_cobalt_thread_setschedparam_ex the affinity mask will contain a single
>> CPU (supposedly the current one).
>>>
>>> All methods to control affinity are executed before this point (cmdline args,
>> /proc/xenomai/affinity), so there is no working way to control it.
>>>
>>
>> Not sure I get the problem yet: "some-xenomai-app --cpu-affinity X" seems
>> to work fine, so does setting /proc/xenomai/affinity. Can you describe more
>> concretely what behaves unexpectedly, maybe with a test case?
> 
> Well, it does not work for me.
> 
> ------------------ file test.c
> #define _GNU_SOURCE
> #include <stdio.h>
> 
> #include <sched.h>
> #include <pthread.h>
> 
> static void printaff()
> {
>     cpu_set_t cpuset;
>     pthread_getaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
>     printf("Affinity: ");
>     for(unsigned i = 0; i < 256; ++i)
>     {
>         if(CPU_ISSET(i, &cpuset))
>             printf("%u,", i);
>     }
>     printf("\n");
> }
> 
> int main(int argc, char const *argv[])
> {
> printaff();
> return 0;
> }
> ------------------
> 
> root at buildroot:~# cat /proc/xenomai/affinity
> 0000000f
> 
> root at buildroot:~# /tmp/a.out
> Affinity: 2,
> 
> root at buildroot:~# /tmp/a.out app --cpu-affinity 0,1,2,3
> Affinity: 3,
> 
> I traced the point where affinity collapsed to the
> sc_cobalt_thread_setschedparam_ex call.
> 

Feature, note bug. CPU migration is at odds with (very) low-latency
requirement, so cobalt pins the thread to one of the cores defined by
--cpu-affinity, preferably the current one. There is no point in having
more than a single core in the affinity mask for a real-time thread: we
simply don't want that one to be involved in any load balancing strategy.


-- 
Philippe.



More information about the Xenomai mailing list