From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E6B94EF9002 for ; Wed, 4 Mar 2026 16:20:44 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1245757.1545144 (Exim 4.92) (envelope-from ) id 1vxoxc-0001q6-Fl; Wed, 04 Mar 2026 16:20:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245757.1545144; Wed, 04 Mar 2026 16:20:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoxc-0001pz-D8; Wed, 04 Mar 2026 16:20:32 +0000 Received: by outflank-mailman (input) for mailman id 1245757; Wed, 04 Mar 2026 16:20:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoxb-0001pt-Oq for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:20:31 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ef72ed2-17e6-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 17:20:29 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4806ce0f97bso60915465e9.0 for ; Wed, 04 Mar 2026 08:20:29 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4851a8ae17csm13993845e9.6.2026.03.04.08.20.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 08:20:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0ef72ed2-17e6-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772641228; x=1773246028; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=bFqecisVfpqlBVF4/cTVsR7G7jAGrW7vwDhM9nM84Ig=; b=ehX+R7OSO7gNeQpDiU/Alk8U/NuwtEArdyZ4QvJCdocr69fBrxJhmaZ9ZuX0F10ewb p3hFKUEryB6OR9OZxTgLPsq3DHA0MTXWGsS+YRWLiWWPbBfa2/mmFxbPFzsxcLU+RRck 1zjJOUzXbPMBdENt+VBC8Mf5KYVaBu1fpdlP2gGD5u8zBINaZCWc1m7xQ2NpSTkbuup5 oi/lhU3JQf+as8Jspr7IYL/KbrHqD0axxeb8mdHlxCAbunbOCJ6pku/RPRFYTJsSSG/M hQ0lQGYyGLDTPUpY/nuPM16jgSyLpsXwuD0o/Fra6jWdpH9XxnALSUNfnMPbhuvL9Exz pI8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772641228; x=1773246028; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bFqecisVfpqlBVF4/cTVsR7G7jAGrW7vwDhM9nM84Ig=; b=GSxQyy9A7dx20UQkeVciTkUOp2AxOQ8Pb60/9zhke1X3J/lxFnp4SNFD56ukTCfEqo hp1ObdGcL5nLInNAOOi7gf9YhEM9m0i/EiVX/acirPmNAvsxDUBYRNZUy3HXHKSWUdzt TeyC6JgZ5SXxW9kIeKBqoiugrdjk8YRl7CFXx7M5dMrDlmxrEryF5F49lQfBC6S3HbgQ vQ9HDt90514c8zxozhoBnnnC6AZIgNz8n/rVrQNCzE8g6TLU9bXBm0HvbSKmcl3l8b1H To68uFieJJm1pM7HxSI4RhxGeHVUOA552SKia52WS+5NYl4gFfI7zmPpCU9158KCd/nY 79vQ== X-Forwarded-Encrypted: i=1; AJvYcCVHcBazYyM75AjUBRSLcAgYG4BbWvp3DEBgF0ezt4QR4azx9snm2ahDUiRp4FPvWZpXaaQe7rrdEE0=@lists.xenproject.org X-Gm-Message-State: AOJu0YwGc/vaLysWyexSHjjQRi9mxPnOjOS3dSBxYRJCbNeSwcObtbDn x1tnNz/fAilDn+jJAFvyGuFHIG3MI47AggLvibxyRJiojtsHeuSXBXyq4385yo9Jzw== X-Gm-Gg: ATEYQzyXkFeQYGrrVFk8ZLwIsj/an1C2hRKW8q+G8PoYtClVgrMxKfMvlnxErZdXNph 5JgqfPZzLRmNllDpQiMTbXDz3vcXqGJpFlIjC3eB3/U2zUpEYG17wyoM830WkD0YhbS37XmU7Nj eyNTZbME5Oktdl3fG89gf5x2u4d0hXW7ThnSmPML25Wq8wSCAMINTZHSWpMsLYXcGkXV2UlncM6 R7xgERPTHKcV/1I2onXFglAXY/wbgSF8StxM0vm8FedOVB4zbkCb00Qej3QsA2+LQpE9wk+n7Hy hytaUpOQuQhHUsialMlcLcKZhVduyHUZyqrSsTbDASqGdQN7Myn6d9dYWVZdUQ2JNSl8+ha1Sw/ YC0Z6fTf0dy5gWLC7kCCqZv2XpxsZAq2WlpH/a6L3UDgO91HKOziFCx4M/jgBtbeCHTIUUdxoHo mRnpkRS6rDL+gs7dZAdGZriGX2Qe7bEZC9lVPVmgHuTasKgkHV/7Khl4oUIHAzRoYFWinhrzbsX myhcMjHsX45pFQ= X-Received: by 2002:a05:600c:1d0c:b0:483:78e1:784 with SMTP id 5b1f17b1804b1-4851984a312mr40672175e9.4.1772641228106; Wed, 04 Mar 2026 08:20:28 -0800 (PST) Message-ID: <91d2bd4b-7ca8-45fe-9e60-071d2cf2d327@suse.com> Date: Wed, 4 Mar 2026 17:20:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/10] xen/page_alloc: Extract code for consuming claims into inline function To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7dd887bc26830d6c50e5bc2606391963e65285a1.1772098423.git.bernhard.kaindl@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <7dd887bc26830d6c50e5bc2606391963e65285a1.1772098423.git.bernhard.kaindl@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -518,6 +518,34 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages) > return d->tot_pages; > } > > +/* Release outstanding claims on the domain, host and later also node */ > +static inline Generally we prefer to avoid "inline" in .c files. This is better left to the compiler. Furthermore while we have a few examples of this kind of line split, it's clearly not the preferred form. You'll find ample well-formed static functions in this one source file alone. > +void release_outstanding_claims(struct domain *d, unsigned long release) > +{ > + ASSERT(spin_is_locked(&heap_lock)); > + BUG_ON(outstanding_claims < release); > + outstanding_claims -= release; > + d->outstanding_pages -= release; > +} > + > +/* > + * Consume outstanding claimed pages when allocating pages for a domain. > + * NB. The alloc could (in principle) fail in assign_pages() afterwards. In that > + * case, the consumption is not reversed, but as claims are used only during > + * domain build and d is destroyed if the build fails, this has no significance. > + */ > +static inline > +void consume_outstanding_claims(struct domain *d, unsigned long allocation) > +{ > + if ( !d || !d->outstanding_pages ) > + return; > + ASSERT(spin_is_locked(&heap_lock)); Why is this not the first thing in the function? > @@ -1048,29 +1075,8 @@ static struct page_info *alloc_heap_pages( > total_avail_pages -= request; > ASSERT(total_avail_pages >= 0); > > - if ( d && d->outstanding_pages && !(memflags & MEMF_no_refcount) ) > - { > - /* > - * Adjust claims in the same locked region where total_avail_pages is > - * adjusted, not doing so would lead to a window where the amount of > - * free memory (avail - claimed) would be incorrect. > - * > - * Note that by adjusting the claimed amount here it's possible for > - * pages to fail to be assigned to the claiming domain while already > - * having been subtracted from d->outstanding_pages. Such claimed > - * amount is then lost, as the pages that fail to be assigned to the > - * domain are freed without replenishing the claim. This is fine given > - * claims are only to be used during physmap population as part of > - * domain build, and any failure in assign_pages() there will result in > - * the domain being destroyed before creation is finished. Losing part > - * of the claim makes no difference. > - */ Much of this comment is lost. Parts have been moved, but I think another part (in particular the first paragraph) wants to be retained here. Plus in general when rearranging code it is best to take the original commentary as is (typo or factual corrections of course included as necessary). Jan