From: Philippe Gerum <rpm@xenomai.org>
To: Bryan Butler <Bryan.Butler@kratosdefense.com>
Cc: Russell Johnson <russell.johnson@kratosdefense.com>,
"xenomai@lists.linux.dev" <xenomai@lists.linux.dev>
Subject: Re: [External] - Re: System hanging when using condition variables
Date: Wed, 28 Sep 2022 12:37:44 +0200 [thread overview]
Message-ID: <878rm37pd3.fsf@xenomai.org> (raw)
In-Reply-To: <87czbf7pp5.fsf@xenomai.org>
Philippe Gerum <rpm@xenomai.org> writes:
> Bryan Butler <Bryan.Butler@kratosdefense.com> writes:
>
>> [[S/MIME Signed Part:Undecided]]
>> Philippe,
>>
>> I have observed a couple of odd things, and wanted to see if these were
>> intentional or not:
>>
>> 1. According to the documentation on evl_attach_thread(), the CPU affinity
>> is locked to a the single CPU on which the thread is running at the time.
>> Although one can call sched_setaffinity(), at the cost of a one-time in-band
>> switch, it doesn't appear that this actually changes the affinity
>> settings.
Are you targeting a sibling thread with sched_setaffinity()
(i.e. passing a non-zero, valid pid argument), or is sched_setaffinity()
applied to self (i.e. zero pid)?
>
>> I can work
>> around this issue if necessary, but it may constrain the amount of
>> parallelism we can achieve. I can work around the second issue as well, but
>> it will make for some kind of ugly code.
>>
>
> I've been using the worker pool pattern here in many occasions with EVL
> threads, the core does affect this
s/does/does NOT/
--
Philippe.
next prev parent reply other threads:[~2022-09-28 10:41 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-19 21:38 System hanging when using condition variables Russell Johnson
2022-09-20 6:55 ` Philippe Gerum
2022-09-20 14:31 ` [External] - " Russell Johnson
2022-09-21 14:53 ` Russell Johnson
2022-09-22 14:26 ` Philippe Gerum
2022-09-22 15:25 ` [External] - " Bryan Butler
2022-09-23 19:56 ` Bryan Butler
2022-09-24 8:21 ` Philippe Gerum
2022-09-25 14:59 ` Philippe Gerum
2022-09-25 16:32 ` Philippe Gerum
2022-09-26 14:20 ` Bryan Butler
2022-09-27 22:05 ` Russell Johnson
2022-09-27 23:04 ` Russell Johnson
2022-09-28 1:08 ` Bryan Butler
2022-09-28 10:06 ` Philippe Gerum
2022-09-28 10:37 ` Philippe Gerum [this message]
2022-09-28 9:59 ` Philippe Gerum
2022-09-28 18:35 ` Russell Johnson
2022-09-29 7:04 ` Philippe Gerum
2022-09-29 18:32 ` Russell Johnson
2022-10-01 4:38 ` Russell Johnson
2022-10-04 15:50 ` Philippe Gerum
2022-10-10 17:04 ` Russell Johnson
2022-10-12 16:11 ` Russell Johnson
2022-10-12 16:24 ` Eric Kuzara
2022-11-03 18:13 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rm37pd3.fsf@xenomai.org \
--to=rpm@xenomai.org \
--cc=Bryan.Butler@kratosdefense.com \
--cc=russell.johnson@kratosdefense.com \
--cc=xenomai@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.