RE: affinity of main thread is bound to current core
> -Original Message-
> From: Philippe Gerum
> Sent: Donnerstag, 22. August 2019 17:29
> To: Lange Norbert ; Jan Kiszka
> ; Xenomai (xenomai@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 8/22/19 5:16 PM, Lange Norbert via Xenomai wrote:
> >> -Original Message-
> >> From: Jan Kiszka
> >> Sent: Donnerstag, 22. August 2019 16:52
> >> To: Lange Norbert ; Xenomai
> >> (xenomai@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
> >
> > #include
> > #include
> >
> > 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@buildroot:~# cat /proc/xenomai/affinity 000f
> >
> > root@buildroot:~# /tmp/a.out
> > Affinity: 2,
> >
> > root@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.
Why is all that trickery in setup reading /proc/xenomai/affinity,
parsing --cpu-affinity, and setting the resulting affinity when
soon thereafter *the same setup* will call pthread_setschedparam,
destroying its previous work?
Is that a feature to warm up the CPU, aside of sending me on a
goose chase...
This is the C main thread, even the most unnecessary thread I start with
__STD(pthread_create) will inherit that mask.
Sorry, but I have a hard time figuring out a single argument for that "feature".
I would understand if you bind the thread to a core, potentially affecting the
affinity mask,
as soon the user explicitly kicked that thread into a realtime priority.
Is the affinity mask even affecting cobalt threads that don’t get demoted
(would be a precondition for low-latency)?
Norbert
This message and any attachments are solely for the use of the intended
recipients. They may contain privileged and/or confidential information or
other information protected from disclosure. If you are not an intended
recipient, you are hereby notified that you received this email in error and
that any review, dissemination, distribution or copying of this email and any
attachment is strictly prohibited. If you have received this email in error,
please contact the sender and delete the message and any attachment from your
system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
Re: affinity of main thread is bound to current core
On 8/22/19 5:16 PM, Lange Norbert via Xenomai wrote:
>> -Original Message-
>> From: Jan Kiszka
>> Sent: Donnerstag, 22. August 2019 16:52
>> To: Lange Norbert ; Xenomai
>> (xenomai@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
>
> #include
> #include
>
> 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@buildroot:~# cat /proc/xenomai/affinity
> 000f
>
> root@buildroot:~# /tmp/a.out
> Affinity: 2,
>
> root@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.
RE: affinity of main thread is bound to current core
> -Original Message-
> From: Jan Kiszka
> Sent: Donnerstag, 22. August 2019 16:52
> To: Lange Norbert ; Xenomai
> (xenomai@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
#include
#include
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@buildroot:~# cat /proc/xenomai/affinity
000f
root@buildroot:~# /tmp/a.out
Affinity: 2,
root@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.
Norbert
This message and any attachments are solely for the use of the intended
recipients. They may contain privileged and/or confidential information or
other information protected from disclosure. If you are not an intended
recipient, you are hereby notified that you received this email in error and
that any review, dissemination, distribution or copying of this email and any
attachment is strictly prohibited. If you have received this email in error,
please contact the sender and delete the message and any attachment from your
system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
Re: affinity of main thread is bound to current core
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? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
