Re: [pve-devel] [PATCH] Update cpu.weight default to match documented default

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 24/08/2022 um 10:26 schrieb Fiona Ebner:
> Am 24.08.22 um 01:56 schrieb Matt Corallo:
>>
>>
>> On 8/19/22 6:08 AM, Fiona Ebner wrote:
>>> Hi,
>>>
>>> On 16.08.22 05:49, Matt Corallo wrote:
>>>> Proxmox documentation describes the default CPU weight as 1024 in
>>>> numerous places. However, when unset, the Linux default CGROUP
>>>> weight is 100.
>>>>
>>>
>>> I'd rather update the documentation in all places, because most likely
>>> it just wasn't adapted to mention the cgroup2 default yet. Some places
>>> already do mention both defaults, e.g. 'man 5 qm.conf'
>>
>> Hmm, am I understanding that correctly that now I have to figure out if
>> I'm using cgroup2 or cgroup1 to figure out if the default is 1024 or
>> 100? Or are modern PVE's all running cgroup2 and the UI simply needs to
>> be updated universally to say that the default is now 100?
>>
>> Matt
>>
> 
> PVE 7.x uses cgroupv2 by default, so reporting the new default in the UI
> would be correct for most installations. That said, we do still support
> cgroupv1[0], so ideally, the default in the UI would be shown depending
> on the cgroup version the node is actually running.
> 
> I think this was the plan, but it never got realized. This (not yet
> applied) patch[1] would expose the cluster node's cgroup version to
> other nodes, to be used by the frontend.
> 
> @Thomas: Is this still the plan? If it is, I'll cook up a v2 adding UI
> and doc patches.

Could be nice, systemd will drop cgroup v1 support completely at EOY 2023[0]
and so we should be able to still offer opt-in support for cgroup v1 in Proxmox
VE 8.x, and so ~ 2026 which may help some users that are still stuck on some
legacy, extended LTS CTs, and after that distro's like Ubuntu 16.04 (the last
Ubuntu LTS with an to old systemd for automatic v2 support) will be EOL anyway.


Note that I also stumbled over the following, which may be worth investigating
if I didn't read it wrong:

> Hmm, cgroupv1 named hiearchies should still be available even on
> cgroupv2 hosts. I am pretty sure nspawn at least should have no
> problem with running old cgroupv1 payloads on a cgroupv2 host.
> 
> Isn't this issue just an artifact of the fact that LXD doesn't
> pre-mount cgroupfs? Or does it do so these days? because systemd's
> PID1 since time began would just use the cgroup setup it finds itself
> in if it's already mounted/set up. And only mount and make a choice
> between cgroup1 or cgroupv2 if there's really nothing set up so far.
> 
> Because of that I see no reason why old systemd cgroupv1 payloads
> shouldn#t just work on cgroupv2 hosts: as long as you give them a
> pre-set-up cgroupv1 environemnt, and nothing stops you from doing
> that. In fact, this is something we even documented somewhere: what to
> do if the host only does a subset of the cgroup stuff you want, and
> what you have to do to set up the other stuff (i.e. if host doesn't
> manage your hierarchy of choice, but only others, just follow the same
> structure in the other hierarchy, and clean up after yourself). This
> is what nspawn does: if host is cgroupv2 only it will set up
> name=systemd hierarchy in cgroupv1 itself, and pass that to the
> container.
-- [1]


[0]: https://github.com/systemd/systemd/pull/24086/files
[1]: https://lists.freedesktop.org/archives/systemd-devel/2022-July/048123.html