[systemd-devel] Is it meant to be possible to set IO[Read|Write]BandwidthMax on a slice ?
Hadrien Grasland
hadrien.grasland at ijclab.in2p3.fr
Thu Apr 8 10:24:56 UTC 2021
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.
In the following discussion, I'll focus on capping the read bandwidth of
/dev/sda for the sake of keeping my examples short, but if I can get
this to work, the idea would be to cap the read and write bandwidth of
all storage devices.
>From
https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
, I understand that I should be able to achieve the intended goal by...
* Running something like `systemctl set-property --runtime user.slice
IOReadBandwidthMax='/dev/sda 1M'` before the benchmark
* Running something like `systemctl set-property --runtime user.slice
IOReadBandwidthMax=` after the benchmark.
However, this is not effective, as can be checked by running `hdparm
-t`, which still observes the full disk bandwidth.
I have tried the following variants:
* `systemd-run -p IOReadBandwidthMax='/dev/sda 1M' -t bash` works
(hdparm only sees 1 MB/s within the resulting shell)
* `systemd-run -t bash` followed by `systemctl set-property --runtime
<new unit> IOReadBandwidthMax='/dev/sda 1M'` also works (hdparm only
sees 1 MB/s).
* More specifically targeting individual users' slices
(user-<uid>.slice) doesn't work.
This looks like a cgroups or systemd bug to me, but I thought I would
cross-check with you before reporting this to my distribution's
bugtracker (my distro packages systemd 246, which is just below your
minimal version criterion for upstream bug reports).
Should I be able to set I/O bandwidth caps on a top-level slice like
user.slice, or is it expected that I can only do it on individual services?
Cheers,
Hadrien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210408/deb0081d/attachment.htm>
More information about the systemd-devel
mailing list