On Thu, 24 Jul 2025 23:21:49 +0200, Richard Weinberger wrote: > On Sun, Jul 13, 2025 at 7:25 PM Tiwei Bie <tiwei....@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
