The Hurd servers themselves are multithreaded, so they should be able to benefit of the parallelism brought by SMP/Multicore boxes. This needs testing as SMP support has recently been added to Mach.
Mach used to be running on SMP boxes like the Intel iPSC/860, so principally has the required infrastructure. It has recently been enhanced to support nowadays' SMP standards like ACPI.
However, GNU Mach's Linux device driver glue code isn't SMP-safe so build with --disable-linux-groups to test SMP and use rumpdisk to provide disk access.
To build an SMP supported gnumach with kdb: ../configure --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups
This will by default allow you to boot with one core isolated to the default processor set, and all the other detected cpus will be in the slave processor set. The slave processors need to be enabled per-task using RPCs to manipulate processor sets.
See https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html for a test program that can enable a task to use the slave processors by calling ./smp /bin/bash for example.
Unfortunately, there are race conditions causing hangs or crashes in Mach when attempting to boot a full SMP system, (if you revert the slave processor pinning commit). This is what needs to be debugged one-by-one by running each translator using ./smp until we can squash these race condition bugs.
There are follow-up issues about multiprocessing and multithreading.