From: Tiwei Bie <tiwei.bie@linux.dev>
To: richard.weinberger@gmail.com
Cc: richard@nod.at, anton.ivanov@cambridgegreys.com,
johannes@sipsolutions.net, linux-um@lists.infradead.org,
tiwei.btw@antgroup.com, tiwei.bie@linux.dev
Subject: Re: [RFC PATCH 0/4] um: Add SMP support
Date: Fri, 25 Jul 2025 19:42:04 +0800 [thread overview]
Message-ID: <20250725114204.1122115-1-tiwei.bie@linux.dev> (raw)
In-Reply-To: <CAFLxGvxiCzLEYX2yuexgidUZ1fgtF5F988X2Cz4L_7ni1JYKXA@mail.gmail.com>
On Thu, 24 Jul 2025 23:21:49 +0200, Richard Weinberger wrote:
> On Sun, Jul 13, 2025 at 7:25 PM Tiwei Bie <tiwei.bie@linux.dev> wrote:
> > Here are some steps to try out SMP support in UML:
> >
> > 1. Build UML with CONFIG_SMP=y and, for example, CONFIG_NR_CPUS=8.
> >
> > 2. Launch a UML instance with, for example, 8 virtual CPUs.
> >
> > $ ./linux mem=16G ncpus=8 nohz=n seccomp=on init=/bin/sh \
> > ubd0=$your_rootfs_image
>
> That's pretty cool! The implementation looks *much* simpler than I
> have expected.
Thanks! :)
>
> Can you please explain a little more the details behind it?
> e.g. Why ptrace is not supported?
> Does it support true SMP (IOW SMP within the kernel)?
Yeah, SMP within the kernel is supported. SMP across different
guest processes is also supported. Currently, the limitation is
that multi-threading within the same guest process doesn't support
true SMP in userspace, as it would require converting the stub into
a multi-threaded implementation. Technically, ptrace could also be
supported, but it would require redesigning the stub as well.
The general design is that each UML virtual CPU is represented as
a host thread. Similar to other architectures, the kthreads and
normal threads (when running in kernel mode) can be scheduled and
executed simultaneously on these CPUs (i.e., on these host threads).
However, the userspace code of normal threads still runs within
their corresponding single-threaded stubs (there is a bug in this
part in this series, which will be fixed in the next version).
>
> I gave it a try on my machine and noticed that the UML process eats a
> lot of CPU time
> on the host side.
> Tracing showed that some (not all) CPU threads perform these syscalls
> over and over:
> rt_sigprocmask(SIG_UNBLOCK, 0xe081bdf0, NULL, 8) = 0
> rt_sigprocmask(SIG_BLOCK, 0xe081bdf0, 0xe081be70, 8) = 0
> timer_gettime(2, 0xe081bdd0)
Sorry for the confusion. That was a bug. I've fixed it. I'll send out
the new version this weekend.
Regards,
Tiwei
prev parent reply other threads:[~2025-07-25 12:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-13 17:25 [RFC PATCH 0/4] um: Add SMP support Tiwei Bie
2025-07-13 17:25 ` [RFC PATCH 1/4] um: Stop tracking virtual CPUs via mm_cpumask() Tiwei Bie
2025-07-13 17:25 ` [RFC PATCH 2/4] um: Remove unused cpu_data and current_cpu_data macros Tiwei Bie
2025-07-13 17:25 ` [RFC PATCH 3/4] um: vdso: Implement __vdso_getcpu() via syscall Tiwei Bie
2025-07-13 17:25 ` [RFC PATCH 4/4] um: Add SMP support Tiwei Bie
2025-07-14 12:37 ` [RFC PATCH 0/4] " Benjamin Berg
2025-07-14 14:56 ` Tiwei Bie
2025-07-24 21:21 ` Richard Weinberger
2025-07-25 11:42 ` Tiwei Bie [this message]
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=20250725114204.1122115-1-tiwei.bie@linux.dev \
--to=tiwei.bie@linux.dev \
--cc=anton.ivanov@cambridgegreys.com \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
--cc=richard.weinberger@gmail.com \
--cc=richard@nod.at \
--cc=tiwei.btw@antgroup.com \
/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.