All of lore.kernel.org
 help / color / mirror / Atom feed
From: JiajunDu <wonderboy512@163.com>
To: xenomai@lists.linux.dev
Subject: A problem regarding SMP
Date: Wed, 22 May 2024 10:11:29 +0000	[thread overview]
Message-ID: <Zk3E0XfaeikSP2Kr@2956c958a175> (raw)

Hello!

Currently I encountered a problem with SMP while using linux-evl core.

I created multiple kernel processes sequentially in the kernel state using
`evl_run_kthread` and would like to have them run in parallel on multiple
CPUs, but the parallelism I was expecting is not happening in EVL core.

After reading the relevant code in the EVL kernel, I discovered the reason
as follows. When calling `evl_run_kthread` in the master process to create
multiple processes sequentially, the master process creates the first process
first and then waits for the first process to finish initializing:

wait_for_completion(&kthread->done);

The newly created process enters the `kthread_trampoline` function and switches
the OOB state first, then calls `irq_work_queue` to put the inband irq_work
that wakes up the master process into the current CPU. However, this results
in that the inband irq_work that wakes up the master process having no way to
be handled until the first created process finishes executing, because it is
OOB. This would also cause the creation and running of the second process being
delayed, since these events occur in the master process. So in summary, there
is no way to run all the processes in parallel.

By the way, the /kernel/evl/thread.c file also exists a comment explaining this
problem:

/*
* We are now running OOB, therefore __evl_run_kthread() can't
* start us before we enter the dormant state because
* irq_work_queue() schedules the in-band wakeup request on
* the current CPU. If we fail switching to OOB context,
* kthread->status tells __evl_run_kthread() not to start but
* cancel us instead.
*/

Now I'm thinking that theoretically this phenomenon is correct for RTOS, since
the main process that creates the new processes is not OOB, so it does should
be woken up using inband ways. But this does cause a lot of wasted CPU
resources in SMP environments, because it would have been possible to have the
inband processes and the OOB processes running at the same time on different
CPUs.

So, here I would like to ask, should this problem to be solved? And is there
anyone in the community working on this?

Best regards,
Jiajun


             reply	other threads:[~2024-05-22 10:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 10:11 JiajunDu [this message]
2024-05-22 12:32 ` A problem regarding SMP Philippe Gerum
2024-05-23  3:50   ` [PATCH] test: smp: achieve parallelism by using barriers to synchronize processes JiajunDu
  -- strict thread matches above, loose matches on Subject: below --
2024-05-23  3:47 A problem regarding SMP JiajunDu
2024-05-23  7:52 ` Philippe Gerum
2024-05-23  8:04   ` Philippe Gerum
2024-05-23 11:33     ` JiajunDu
2024-05-23 13:32       ` 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=Zk3E0XfaeikSP2Kr@2956c958a175 \
    --to=wonderboy512@163.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.