Hi Paul, Thank you for the ping, much appreciated! Paul Gevers <elbrus@debian.org> writes: > Hi Nicholas, > > Thanks for your bug report. > > On 17-04-2021 00:27, Nicholas D Steeves wrote: >> It looks like Debian's Docker package has broken cgroup2 support >> (#985481), so either that bug should be fixed, or issues.dbk (around >> L66) should document that cgroup2 support may be broken in Docker >> containers on Bullseye. > > I fail to see what you had in mind. Can you make your proposal a bit > more concrete? I haven't made backtracking to line 66 easier by > reorganizing that particular file, but the only place where we discuss > cgroups v2 is in OpenStack and that's much later. > Wonderful to hear that OpenStack supports cgroups v2 :-) It appears Podman may also support them (I haven't yet tested with Podman). To be honest, I'm not sure what would be the best way solve what appears to have become a chicken & egg problem, namely that cgroups v2 support has existed for years, but application support for it is still poor. I'm also not sure if the iogroup support is still btrfs-only ( https://engineering.fb.com/2018/10/30/open-source/linux/ ). I think it was when upgrading to buster that I was surprised by how badly the switch to mq_deadline affected interactivity/UI latency under load, and it looks like cgroups v2 are supposed to be a mitigation for this--even for desktop users. There's an excellent discussion at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1851783 mq_deadline also doesn't support the "idle" class via "ionice". Also, I must apologise, because I previously misunderstood what was required for partitioning the available I/O bandwidth into slices. It appears that the new multiqueue schedulers do not support it ( https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/pdf/managing_monitoring_and_updating_the_kernel/managing-monitoring-and-updating-the-kernel.pdf , p118) I guess to concretise my proposal, it seems like we should (in no particular order) 1. announce what software supports the new cgroupv2 2. say a line or two about how it can be used to mitigate the effect of background/bulk jobs on desktop interactivity 3. be used to set resource limitations on server processes and containers 4. list software with confirmed support and confirmed missing support * so far it looks like we have OpenStack, but also need to add systemd, and libvirt to "supporting" https://fedoraproject.org/wiki/Changes/CGroupsV2 * and LXC and Docker for "missing support" * Podman and Flatpak? 5. for the systemd+server process case, it seems like it would be useful to point sysadmins to some documentation about how to use this new technology. Eventually I think it would be really nice if all non-interactive not-time-sensitive background processes were ioniced. eg: if a simple file copy or move will create a bandwidth-starved situation that will block the GUI, and deploying a policy of ionicing such function will prevent the GUI from blocking, then I think we ought to do that :-) As that policy does not yet exist (AFAIK, unless systemd defaults have changed), something like "preliminary (or early, or partial) cgroups v2" support appears to be the most accurate phrase. I think we should announce something, because issues resulting from a high iowait have been getting worse over the last decade. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature