From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 0280E9072A for ; Fri, 2 Sep 2022 08:34:07 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id ECA832C8D2 for ; Fri, 2 Sep 2022 08:34:06 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 2 Sep 2022 08:34:06 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id BF7A4433D2; Fri, 2 Sep 2022 08:33:59 +0200 (CEST) Message-ID: Date: Fri, 2 Sep 2022 08:33:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Thunderbird/105.0 Content-Language: en-GB To: Proxmox VE development discussion , Fiona Ebner , Matt Corallo References: <5a13fe68-3c53-b986-2c09-a80d31db225d@proxmox.com> <837ccb7a-a073-09ac-f4ab-708b797d41b1@bluematt.me> <0342b548-cfb0-0737-2f1d-310b14291680@proxmox.com> From: Thomas Lamprecht In-Reply-To: <0342b548-cfb0-0737-2f1d-310b14291680@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.005 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH] Update cpu.weight default to match documented default X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2022 06:34:07 -0000 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