mirror of
https://github.com/SELinuxProject/selinux
synced 2025-01-02 03:32:13 +00:00
93902fc834
Use the newly introduced selinux_restorecon_parallel(3) in setfiles/restorecon and a -T option to both to allow enabling parallel relabeling. The default behavior without specifying the -T option is to use 1 thread; parallel relabeling must be requested explicitly by passing -T 0 (which will use as many threads as there are available CPU cores) or -T <N>, which will use <N> threads. === Benchmarks === As measured on a 32-core cloud VM with Fedora 34. Not a fully representative environment, but still the scaling is quite good. WITHOUT PATCHES: $ time restorecon -rn /usr real 0m21.689s user 0m21.070s sys 0m0.494s WITH PATCHES: $ time restorecon -rn /usr real 0m23.940s user 0m23.127s sys 0m0.653s $ time restorecon -rn -T 2 /usr real 0m13.145s user 0m25.306s sys 0m0.695s $ time restorecon -rn -T 4 /usr real 0m7.559s user 0m28.470s sys 0m1.099s $ time restorecon -rn -T 8 /usr real 0m5.186s user 0m37.450s sys 0m2.094s $ time restorecon -rn -T 16 /usr real 0m3.831s user 0m51.220s sys 0m4.895s $ time restorecon -rn -T 32 /usr real 0m2.650s user 1m5.136s sys 0m6.614s Note that the benchmarks were performed in read-only mode (-n), so the labels were only read and looked up in the database, not written. When fixing labels on a heavily mislabeled system, the scaling would likely be event better, since a larger % of work could be done in parallel. Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> |
||
|---|---|---|
| .. | ||
| ru | ||
| Makefile | ||
| restore.c | ||
| restore.h | ||
| restorecon_xattr.8 | ||
| restorecon_xattr.c | ||
| restorecon.8 | ||
| setfiles.8 | ||
| setfiles.c | ||