Le 08/04/2021 à 18:08, Lennart Poettering a écrit :
On Do, 08.04.21 17:19, Hadrien Grasland (hadrien.grasland@xxxxxxxxxxxxxxx) wrote:
Le 08/04/2021 à 16:11, Lennart Poettering a écrit :
On Do, 08.04.21 12:24, Hadrien Grasland (hadrien.grasland@xxxxxxxxxxxxxxx) wrote:
Hi everyone,
In a scenario where running benchmarks on dedicated hardware is not
possible, I'm trying to momentarily cap the I/O bandwidth used by
interactive user sessions while benchmarks are running, in order to improve
the stability of said benchmark's I/O performance.
Is this on cgroupsv1 or cgroupsv2?
IIRC there was some issue that the block io controller wasn't fully
recursive on cgroupsv1. It should work on cgroupsv2.
This is on a hybrid cgroup configuration. I (perhaps mistakenly) assumed
that modern systemd (v246) will use the cgroups v2 hierarchy in that case,
even though cgroups v1 is still exposed for compatibility with older apps.
No, hybrid mode means all controllers operate in cgroupsv1 mode. It's
just that the controller-less cgroupsv2 hierarchy is also mounted.
hybrid mode was a mistake, we should never have added that, it's just
a massive maintainance burden for little gain.
I see, thanks for the clarification.
I also checked that setting block IO caps on a session-xyz.scope (which
is the last systemd hierarchy node above the interactive processes that
I want to cap) does indeed work, which is consistent with your former
recollection that this might be an issue with cgroupsv1 block io
controller not being recursive.
Which gives me a dirty workaround idea for a way to handle my use case
until slurm get their cgroups v2 support in shape: "just" write a
program that parses the output of systemd-cgls, enumerates every
last-level unit below user.slice, and runs systemctl set-property on
that. That's both ugly and TOCTOU-racy (won't handle newly spawned
units, and must account for units that go away), but might work well
enough for my purposes...
Hadrien
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
