From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 1AAFC1FF179 for ; Wed, 15 Oct 2025 16:31:06 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6F7051E7C3; Wed, 15 Oct 2025 16:31:24 +0200 (CEST) Message-ID: <04c02890-b538-407a-bcf8-f35f5912e4ab@proxmox.com> Date: Wed, 15 Oct 2025 16:31:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Daniel Kral References: <20250930142021.366529-1-d.kral@proxmox.com> <20250930142021.366529-2-d.kral@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20250930142021.366529-2-d.kral@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1760538678863 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.021 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH qemu-server 1/1] config: only fetch necessary default values in get_derived_property helper 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 30.09.25 um 4:20 PM schrieb Daniel Kral: > get_derived_property(...) is called in the semi-hot path of the HA > Manager's static load scheduler to retrieve the static stats of each VM. > As the defaults are only needed in certain cases and for a very small > subset of properties in the VM config, get those separately when needed. > > Signed-off-by: Daniel Kral > --- > get_current_memory(...) is still quite costly here, because it calls > parse_memory(...), which calls > PVE::JSONSchema::parse_property_string(...), which adds up for many > guest configurations parsed in every manage(...) call, but this already > helps quite a lot. If this really is a problem, we could do our own parsing, i.e. returning the value if the property string starts with \d+ or current=\d+ and falling back to get_current_memory() if it doesn't. Of course also using the default from $memory_fmt if not set. > > src/PVE/QemuConfig.pm | 8 +++----- > src/PVE/QemuServer.pm | 6 ++++++ > 2 files changed, 9 insertions(+), 5 deletions(-) > > diff --git a/src/PVE/QemuConfig.pm b/src/PVE/QemuConfig.pm > index d0844c4c..078c87e0 100644 > --- a/src/PVE/QemuConfig.pm > +++ b/src/PVE/QemuConfig.pm > @@ -582,12 +582,10 @@ sub load_current_config { We could go a step further and save the three defaults we are interested in during module load into variables. Then you also save the hash accesses into $confdesc and $memory_fmt. > sub get_derived_property { > my ($class, $conf, $name) = @_; > > - my $defaults = PVE::QemuServer::load_defaults(); > - > if ($name eq 'max-cpu') { > - my $cpus = > - ($conf->{sockets} || $defaults->{sockets}) * ($conf->{cores} || $defaults->{cores}); > - return $conf->{vcpus} || $cpus; > + my $sockets = $conf->{sockets} || PVE::QemuServer::get_default_property_value('sockets'); > + my $cores = $conf->{cores} || PVE::QemuServer::get_default_property_value('cores'); > + return $conf->{vcpus} || ($sockets * $cores); > } elsif ($name eq 'max-memory') { # current usage maximum, not maximum hotpluggable > return get_current_memory($conf->{memory}) * 1024 * 1024; > } else { Question is, how much do we really need to optimize the function here? I'm not against it, but just want to note that looking at the static usage will always have its limitations in practice (independent of performance). With PSI-based usage, we should only need the static information for to-be-started or to-be-recovered guests rather than all, so performance of get_derived_property() becomes much less relevant. Or what do you think? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel