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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99FECC282D2 for ; Tue, 4 Mar 2025 13:44:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A6656B007B; Tue, 4 Mar 2025 08:44:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 155206B0082; Tue, 4 Mar 2025 08:44:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01CF26B0085; Tue, 4 Mar 2025 08:44:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D74206B007B for ; Tue, 4 Mar 2025 08:44:00 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7B221121D17 for ; Tue, 4 Mar 2025 13:44:00 +0000 (UTC) X-FDA: 83183987040.22.E77BA55 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf07.hostedemail.com (Postfix) with ESMTP id 2753340005 for ; Tue, 4 Mar 2025 13:43:57 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=F7++99W3; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=1u22BvZP; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=F7++99W3; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=1u22BvZP; spf=pass (imf07.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741095838; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hPx+zsCd34bmXpjRpD9fdbejfFBV7jxFeO2G0fXZMsg=; b=iAaq9Rs8dUQnxKlmQ7bneehNWazTNo0kiSdkIqOvCoNS/2dSGvsYLkYPymWRrWsrR+iUCI rxpLm/bmZT7NKZIikKlxHPpgo1AnEAeQfZs08Lp/plzTI9O0R1PKkIg6VW2LCUuZNpVzM+ rzUYIcxuax/kaEcSzPvqtE3HMZu7oDg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=F7++99W3; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=1u22BvZP; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=F7++99W3; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=1u22BvZP; spf=pass (imf07.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741095838; a=rsa-sha256; cv=none; b=WFl1z8rK27nch5JF8C2+oMtKia9k86EKcWC/ilbacDezGlYBOVDPRSgvEkNa62E5aq0wKY 1NMkI/KBRG2+lyaz3ZJcbAS/+saVC6undOcid0p+USH6vPBtZaEB9OXkUb8BXfIcavLZbP fVGWGUf39O4u8SXjW6lDxH9ziJyvn2s= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 750FB1F74D; Tue, 4 Mar 2025 13:43:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1741095836; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hPx+zsCd34bmXpjRpD9fdbejfFBV7jxFeO2G0fXZMsg=; b=F7++99W35lM3jEjFVHhUCubr2ueul7GB2SEG98b2wDasNGqOH3unkX2Mv0ZEO47F1P9s1x 0tDdcs+X3jih5JIA40KA7qcLa2v/547j9P/3D0nvOxgKWmsjn6dFZcdGA5aaT3RCvCzdcW rI/0whCsndz9SzAoEexJwZDbe+jjIFo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1741095836; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hPx+zsCd34bmXpjRpD9fdbejfFBV7jxFeO2G0fXZMsg=; b=1u22BvZPc3V1zzbvI+oFJa3ci9iYjit0yPgBw1K4wROetsP2gaIStbxTpt/zv0f7ozdtMQ G0ZiBQtotdmMwcAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1741095836; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hPx+zsCd34bmXpjRpD9fdbejfFBV7jxFeO2G0fXZMsg=; b=F7++99W35lM3jEjFVHhUCubr2ueul7GB2SEG98b2wDasNGqOH3unkX2Mv0ZEO47F1P9s1x 0tDdcs+X3jih5JIA40KA7qcLa2v/547j9P/3D0nvOxgKWmsjn6dFZcdGA5aaT3RCvCzdcW rI/0whCsndz9SzAoEexJwZDbe+jjIFo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1741095836; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hPx+zsCd34bmXpjRpD9fdbejfFBV7jxFeO2G0fXZMsg=; b=1u22BvZPc3V1zzbvI+oFJa3ci9iYjit0yPgBw1K4wROetsP2gaIStbxTpt/zv0f7ozdtMQ G0ZiBQtotdmMwcAQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 0107513967; Tue, 4 Mar 2025 13:43:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 2Y0vOZsDx2cTIwAAD6G6ig (envelope-from ); Tue, 04 Mar 2025 13:43:55 +0000 Date: Tue, 4 Mar 2025 14:43:46 +0100 From: Oscar Salvador To: Jinjiang Tu Cc: akpm@linux-foundation.org, muchun.song@linux.dev, david@redhat.com, linux-mm@kvack.org, wangkefeng.wang@huawei.com, sunnanyong@huawei.com Subject: Re: [PATCH v2] mm/hugetlb: fix surplus pages in dissolve_free_huge_page() Message-ID: References: <20250304132106.2872754-1-tujinjiang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250304132106.2872754-1-tujinjiang@huawei.com> X-Rspamd-Action: no action X-Stat-Signature: 1urqi9ki3ugjodp8wnemhc8d5et66k1t X-Rspamd-Queue-Id: 2753340005 X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1741095837-637489 X-HE-Meta: U2FsdGVkX1+CPruBvE4lONgKOHNfJLZe9BXDsB/0f9VdrTZXUx/xq8DWxLcKjxe4hGkvVqdSFEcSfU18KHD+kBtjkY64ntg5bLqu5bFdnUQNw77KsqiNO82Q7m2YmFqxbu4AmiovABO//0pqtjh/qP2a1B9lTqq4+ZuK3ecaqNlsx5K9XI7SIusP5/UBJUSbCSv1nGuN2FVe7FHs4Kru9Y35PaBpAxkE6iyPePYwRVqhPilKM8zZggRMo301OIBhAuJ1Hl8HuBvVaDYAu2t7+fOwkIbCoWQ3NZ3YyFlDyHwbi8QCjjwvpqqlntoIlrD0N46JoOHElfkkKWLiC3+IUK3NJzOxfspwV4ypapOUW0KtO1mfmae0DqQfXcnqj3Ahv1DD06TCEX+w8S7Tgj1eXAoKDDAVLW1o3QPGr+w7bLfeyBQNpI8r7OSamKLYR+OL8RYwBgwTNu7uHGcj8EFPQWmj9mYBXN2yVESCrAU8G9jPTkhFtvIM/1tHPfP6fhGjOZBJNh4x8pL/O/BlXjvmNWnvzDVfy7HhNO4iQDNMY2spR6A9N9i0meNolK3H8Bg6f0xwc1dTck0hoDyCf7ruYtZkI5kM8uSYAXTOX+b5lGmK1CO73Pj5iDQXHwmJf9YGa81tHPprPoXJXNnp/oDigD+gsaDntaMvwaMiZOLuoxY1WvyCqY8vB/VJIbpQWFJkD4aZukxk2jQCi8DebZn8bcb8jAe6waKYJJfzbJFNKK1gn3TEnSFWKPY63veuk9M2nCUSH8Pf8G/geVlzf2ugt0ux3C5v0qp4oIlSqhl2vCXQUQgaJYtZl0FSEIruhDsp+QfAFqcfdnuV8ge1dF2k7R1+aOqYC6I6jue1o4yMU16MtmcUqPeKveTwmS1cTdOkjCinmtMPpkNnELZhRJIYoo+1u/a0MYW4ArhfFgNApQEdOp0NSZNQzAxNeUi/o3GzvT2HFUFRz5WQuPlO4Ec eKb2GgXS BNHg397jRTuFTc5AwiIY9cS8hY9gtBCI9tUOGRtvDcQIgRqY8nQaWhM727hiGtEUrXCssCFfr3gC4Hitd2QEasOptdItFFtPBEQhAruAFgWRfkJpvGvLn9eU4Vi4Gna8WACR3vAvYWZEUwtLEZgQeQXemFEZD/tONnWEvIkiLtrlBoMrLrUPhNgpihQJU++BZGU3u6NmQcJmL+5CT36rrklIN6Uv+0l7usR4TH3VYZcAcZBQe1G+1VAgt4eF4fKgMxi/SrdrdoUnDlDK59QmzkWnHxfix6ygbgak4B5u8doZU69m269L+cy+gndR+o1JSPK+c/P78fnNPmVU/KAGxhKInBo/7k/NKILgBPZjfbOj1xg4XeL+O3DVw0YAortBrehQK X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 04, 2025 at 09:21:06PM +0800, Jinjiang Tu wrote: > In dissolve_free_huge_page(), free huge pages are dissolved without > adjusting surplus count. However, free huge pages may be accounted as > surplus pages, and will lead to wrong surplus count. > > I reproduce this issue on qemu. The steps are: > 1) Node1 is memory-less at first. Hot-add memory to node1 by executing > the two commands in qemu monitor: > object_add memory-backend-ram,id=mem1,size=1G > device_add pc-dimm,id=dimm1,memdev=mem1,node=1 > 2) online one memory block of Node1 with： > echo online_movable > /sys/devices/system/node/node1/memoryX/state > 3) create 64 huge pages for node1 > 4) run a program to reserve (don't consume) all the huge pages > 5) echo 0 > nr_huge_pages for node1. After this step, free huge pages in > Node1 are surplus. > 6) create 80 huge pages for node0 > 7) offline memory of node1, The memory range to offline contains the free > surplus huge pages created in step3) ~ step5) > echo offline > /sys/devices/system/node/node1/memoryX/state > 8) kill the program in step 4) > > The result: > Node0 Node1 > total 80 0 > free 80 0 > surplus 0 61 > > To fix it, adjust surplus when destroying huge pages if the node has > surplus pages in dissolve_free_hugetlb_folio(). > > The result with this patch: > Node0 Node1 > total 80 0 > free 80 0 > surplus 0 0 > > Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage") > Acked-by: David Hildenbrand > Signed-off-by: Jinjiang Tu Acked-by: Oscar Salvador > @@ -2157,7 +2159,9 @@ int dissolve_free_hugetlb_folio(struct folio *folio) > goto retry; > } > > - remove_hugetlb_folio(h, folio, false); > + if (h->surplus_huge_pages_node[folio_nid(folio)]) > + adjust_surplus = true; > + remove_hugetlb_folio(h, folio, adjust_surplus); > h->max_huge_pages--; > spin_unlock_irq(&hugetlb_lock); > > @@ -2177,7 +2181,7 @@ int dissolve_free_hugetlb_folio(struct folio *folio) > rc = hugetlb_vmemmap_restore_folio(h, folio); > if (rc) { > spin_lock_irq(&hugetlb_lock); > - add_hugetlb_folio(h, folio, false); > + add_hugetlb_folio(h, folio, adjust_surplus); I was about to point this out, but checking v1 I saw that David already that. My alternative would have been to just get rid of the adjust_surplus boolean and to the checking right within the lock cycle e.g: if (h->surplus_huge_pages_node[folio_nid(folio)]) add_hugetlb_folio(h, folio, true); else add_hugetlb_folio(h, folio, false); But I guess that's fine as you already explained. -- Oscar Salvador SUSE Labs