On Mon, Jul 18, 2022 at 8:44 AM Petr Lautrbach <plautrba(a)redhat.com> wrote:
Dan Čermák <dan.cermak(a)cgc-instruments.de> writes:
> On July 15, 2022 9:42:35 PM UTC, Ben Cotton <bcotton(a)redhat.com> wrote:
>>https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel
>>
>>This document represents a proposed Change. As part of the Changes
>>process, proposals are publicly announced in order to receive
>>community feedback. This proposal will only be implemented if approved
>>by the Fedora Engineering Steering Committee.
>>
>>
>>== Summary ==
>>After a system's SELinux mode is switched from disabled to enabled, or
>>after an administrator runs `fixfiles onboot`, SELinux autorelabel
>>will be run in parallel by default.
>>
>>== Owner ==
>>* Name: [[User:plautrba| Petr Lautrbach]]
>>* Email: plautrba(a)redhat.com
>>
>>
>>== Detailed Description ==
>>SELinux tools `restorecon` and `fixfiles` recently gained the ability
>>to relabel files in parallel using the `-T nthreads` option. This
>>option is currently not used in the automatic relabel after reboot.
>>When users want/need the parallel relabeling they have to specify the
>>option explicitly (e.g. `fixfiles -T 0 onboot`). With this change `-T
>>0` (0 == use all available CPU cores) will be the default for
>>`fixfiles onboot` and users will have to use `fixfiles -T 1 onboot` to
>>force it to use only one thread.
>>
>>The rationale is that when autorelabel runs, there are no other
>>resource-intensive processes running on the system, so it's fine (and
>>actually better) to use all available parallelism to speed up the task
>>and get to a fully booted system faster.
>>
>>
>>== Benefit to Fedora ==
>>Faster reboot after switching back to an SELinux enabled system or
>>when triggering autorelabel explicitly.
>
> Just out of curiosity, how large is the speedup typically?
>
>>
It depends on the number of threads your machine has. But you could get some
data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0
restore` on a running system. The following times are reported on my workstation:
[root@P1 ~]# time fixfiles -T 0 restore
Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run
/run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug
/sys/kernel/debug/tracing /sys/kernel/tracing /tmp /var
/ 100.0%
...
real 1m8.488s
user 9m24.755s
sys 0m25.424s
[root@P1 ~]# time fixfiles -T 1 restore
Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run
/run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug
/sys/kernel/debug/tracing /sys/kernel/tracing /tmp /var
/ 100.0%
...
real 4m5.450s
user 3m55.017s
sys 0m10.088s
Also see the original commit message, which compares the run time for
different thread counts on a 32-core machine:
https://github.com/SELinuxProject/selinux/commit/93902fc8340f8a6ee5ba69cc...
It doesn't scale perfectly with the number of cores, but it can speed
up the relabeling up to ~18 times if you have a beefy machine.
I updated the "Benefit to Fedora" section of the proposal with this info.
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.