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 100C4D1A42D for ; Sat, 12 Oct 2024 03:23:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38D9F6B009E; Fri, 11 Oct 2024 23:23:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33D796B009F; Fri, 11 Oct 2024 23:23:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 204A16B00A0; Fri, 11 Oct 2024 23:23:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 024816B009E for ; Fri, 11 Oct 2024 23:23:23 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2A814C11F5 for ; Sat, 12 Oct 2024 03:23:18 +0000 (UTC) X-FDA: 82663504644.04.E07AA5D Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) by imf30.hostedemail.com (Postfix) with ESMTP id 04F1180006 for ; Sat, 12 Oct 2024 03:23:15 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="XhMM/G5Y"; spf=pass (imf30.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728703330; a=rsa-sha256; cv=none; b=WgO8qMpysJ9+ApPA6eOQNe5OJmG3tKeYVcw0ahfwyGRZ0ZqBSwduyJrsOauRIdhC15ORsF 8MTs5dPo+T2p39qrjQB2vHxMK58Tvhccpj/c8jfeUX+8L0MS4kGJuVOEvw6bdbZY+2ttVJ qf3SIhn0c2TFHEnBIxeSzRJth0bR7XU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="XhMM/G5Y"; spf=pass (imf30.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728703330; 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=79Mzw15mpNKD+frrr201ZwC3OMDjPfjgdZyLyMlzeCw=; b=VWDAHIgbzHDkRjLFoUorlXzedZVHgm/wuxkoLX7LkqeBzzDhirR79kV+itTYOEnLmLxsrB WkHuL2Jm7j4SAk7f273tUih4aUBrxPjHeBvLEUNUtYKfqWNnuHU66rOr5c1LTP4UErEDAA d5WCbP/qIDl1BwhdI0Qk5xxRcml4pXU= Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1728703397; h=from:from: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; bh=79Mzw15mpNKD+frrr201ZwC3OMDjPfjgdZyLyMlzeCw=; b=XhMM/G5Y3Ucc3o9uUr2OV7jmiwh7AfKajKQxx1vDgkz4UIhNyN1873N20P2ECySFu8MifW +6mMVa+fuEOcMCdHLZM+w8g8USEhL7u1xEGM16JpopXTPe3DJ4owHUuCOtY+3X9MbyM1id ZRYeqhWYjeyh3Sy1aiclAgquIDtrG6Q= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Subject: Re: [PATCH] mm/hugetlb: Concentrated releases memory when cmdline specifies node requests for large pages X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20241011080543.2422-1-suhua1@kingsoft.com> Date: Sat, 12 Oct 2024 11:22:20 +0800 Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, suhua Content-Transfer-Encoding: quoted-printable Message-Id: References: <20241011080543.2422-1-suhua1@kingsoft.com> To: suhua X-Migadu-Flow: FLOW_OUT X-Stat-Signature: ki5xge6mti115ih7z9u9z8yzb9h5u5nj X-Rspamd-Queue-Id: 04F1180006 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1728703395-961299 X-HE-Meta: U2FsdGVkX19Aq4lqJx83zw2JmpwIrziqbU4rfllKUk2UDW5lf+acBvgjd+kyGB1Tr/0Aspzq4kPzsjAcKrhIxjWR6eu/lC89agm0HFcaNwjdArxguzqOby8K10kQAtTv7uJB2QN9bVs1GUT1HsOl/01apTExMQRqlGW2IPKM1oNFs7FGmtZAS2GFDBK1rhQecX1ARus5zirH7MLPPqIXDfWUMAZJSUE07dh9+95XNhru1ZITGoC08e6Lu0P4vdYXktnVgDD2WhdeLhLHFjrxdIfG7yOf9DfdBhJpLOGeptaJGgVHNBRe2sHYQxsN0Eje0h46ELEahaLnrejutdAVBYHDdTc/q1VdcxnC9oUZ7WOfKU91tEWvkPdvPHs6zczKqbR7+P5u1AfoWG3yCBvypDtyYeo6D8GOWl+64SLj5MevfYzRklSl8SukH+bTPR6yYZv0tY8xIaRAtnvRLSCcX8+mnHjxJy/zvEb7uHbrkOGohZTCdr4pGRZHf5kMU2yA0ColCxC7G6degqp+zV9EpHTDVDyvW/CQ3eaawEfgdBWnPwWRHNIYDTtWssZfgp3Lmuz6loT5+ttjSPm60HKjwSnyY/NxoDI462vz0KlZ50q1rdeTXDLO1sjk8zo8Z3txywKMEnk8iU7a3uc4NQn1B4KVr7AdGp7Vq3oqvbbziXc1PXFGo+yTZNYj9LeYzWIJ9DeT2qOPCHiq32I7PYKH+LmyTnIIyAZV+HshLVjCqPx2S2Pcy1fqiUknss1STnQOnQBrFMfyGwfBVPqfBK78sCBn8jUMjZ3m52tgPHSBCKCO641C2r5vBHx2sMgNN2PfHpksxfsMfsyJ5uDPnEMU6KCtw6H7G04AMtgs2NewY+P0fKXDshw+vEeToaPlgJV8XsSLc5Y7CakNOPQ/N/Ua+kngGPy94j6UeuGMQQgL4yjcQ53vafboCpUrYWG2hoPIwYO38Vvui6k5Wbii1Z/ KrC4Hm2X 0FHMeSv8LoZ4a/OA6EjUfMVdoZL2LO+iGKPVHznFb1PTfwpjjLb4n0HixXjrq9q5FXQy0e6A9J2pv/Yk+ZNoFXe0Um8KPe8M+Ppe7vyN3NkpAsi8wkZ2E59hRY/0pip3WbN4Tq3d1eZzGtdYWA1tTDvKePm9mpNa0ixG4F2Jy+mASkj09fyw5vtzj3qBKp5HzQzDowGkywO8jlVaRcQgL+WH/X7EJGwTsG42w6QLh5I+5VPfKuN2nV0qDfRmCP/tZ8yRNDvxOPx6VMOVeuGcY7yb9tomox8BydmlTZDJmwvmsdORnwYfxZHkGiTbeoXogFJSWUkMvG7cWKAM= 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 Oct 11, 2024, at 16:05, suhua wrote: >=20 > When HVO is enabled and huge page memory allocs are made, the freed = memory > can be aggregated into higher order memory in the following paths, = which > facilitates further allocs for higher order memory. >=20 > echo 200000 > /proc/sys/vm/nr_hugepages > echo 200000 > = /sys/devices/system/node/node*/hugepages/hugepages-2048kB/nr_hugepages > grub=EF=BC=9A default_hugepagesz=3D2M hugepagesz=3D2M hugepages=3D200000= >=20 > Currently not support for releasing aggregations to higher order in = the > following way, which will releasing to lower order. >=20 > grub: default_hugepagesz=3D2M hugepagesz=3D2M = hugepages=3D0:100000,1:100000 >=20 > This patch supports the release of huge page optimizations aggregates = to > higher order memory. >=20 > eg: > cat /proc/cmdline > BOOT_IMAGE=3D/boot/vmlinuz-xxx ... default_hugepagesz=3D2M = hugepagesz=3D2M hugepages=3D0:100000,1:100000 >=20 > Before: > Free pages count per migrate type at order 0 1 2 = 3 4 5 6 7 8 9 10 > ... > Node 0, zone Normal, type Unmovable 55282 97039 99307 = 0 1 1 0 1 1 1 0 > Node 0, zone Normal, type Movable 25 11 345 = 87 48 21 2 20 9 3 75061 > Node 0, zone Normal, type Reclaimable 4 2 2 = 4 3 0 2 1 1 1 0 > Node 0, zone Normal, type HighAtomic 0 0 0 = 0 0 0 0 0 0 0 0 > ... > Free pages count per migrate type at order 0 1 2 = 3 4 5 6 7 8 9 10 > Node 1, zone Normal, type Unmovable 98888 99650 99679 = 2 3 1 2 2 2 0 0 > Node 1, zone Normal, type Movable 1 1 0 = 1 1 0 1 0 1 1 75937 > Node 1, zone Normal, type Reclaimable 0 0 0 = 0 0 0 0 0 0 0 0 > Node 1, zone Normal, type HighAtomic 0 0 0 = 0 0 0 0 0 0 0 0 >=20 > After: > Free pages count per migrate type at order 0 1 2 = 3 4 5 6 7 8 9 10 > ... > Node 0, zone Normal, type Unmovable 152 158 37 = 2 2 0 3 4 2 6 717 > Node 0, zone Normal, type Movable 1 37 53 = 3 55 49 16 6 2 1 75000 > Node 0, zone Normal, type Reclaimable 1 4 3 = 1 2 1 1 1 1 1 0 > Node 0, zone Normal, type HighAtomic 0 0 0 = 0 0 0 0 0 0 0 0 > ... > Free pages count per migrate type at order 0 1 2 = 3 4 5 6 7 8 9 10 > Node 1, zone Normal, type Unmovable 5 3 2 = 1 3 4 2 2 2 0 779 > Node 1, zone Normal, type Movable 1 0 1 = 1 1 0 1 0 1 1 75849 > Node 1, zone Normal, type Reclaimable 0 0 0 = 0 0 0 0 0 0 0 0 > Node 1, zone Normal, type HighAtomic 0 0 0 = 0 0 0 0 0 0 0 0 A good result. But the subject could be changed to: "mm/hugetlb: perform vmemmap optimization batchly for specific = node allocation" >=20 > Signed-off-by: suhua > --- > mm/hugetlb.c | 37 +++++++++++++++++++++++++++++++++---- > 1 file changed, 33 insertions(+), 4 deletions(-) >=20 > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 190fa05635f4..3441d380c90b 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2077,6 +2077,24 @@ static struct folio = *only_alloc_fresh_hugetlb_folio(struct hstate *h, > return folio; > } >=20 > +static struct folio *only_alloc_and_account_fresh_hugetlb_folio( > + struct hstate *h, gfp_t gfp_mask, > + int nid, nodemask_t *nmask) > +{ > + struct folio *folio; > + > + folio =3D only_alloc_fresh_hugetlb_folio(h, gfp_mask, nid, = nmask, NULL); > + if (!folio) > + return NULL; > + > + spin_lock_irq(&hugetlb_lock); > + h->nr_huge_pages++; > + h->nr_huge_pages_node[nid]++; > + spin_unlock_irq(&hugetlb_lock); > + > + return folio; > +} > + > /* > * Common helper to allocate a fresh hugetlb page. All specific = allocators > * should use this function to get new hugetlb pages > @@ -3301,23 +3319,34 @@ static void __init = hugetlb_hstate_alloc_pages_onenode(struct hstate *h, int nid) > { > unsigned long i; > char buf[32]; > + LIST_HEAD(folio_list); > + struct folio *folio, *tmp_f; >=20 > for (i =3D 0; i < h->max_huge_pages_node[nid]; ++i) { > if (hstate_is_gigantic(h)) { > if (!alloc_bootmem_huge_page(h, nid)) > break; > } else { > - struct folio *folio; > gfp_t gfp_mask =3D htlb_alloc_mask(h) | = __GFP_THISNODE; >=20 > - folio =3D alloc_fresh_hugetlb_folio(h, gfp_mask, = nid, > - &node_states[N_MEMORY]); > + folio =3D = only_alloc_and_account_fresh_hugetlb_folio(h, > + gfp_mask, nid, = &node_states[N_MEMORY]); I think we could use only_alloc_fresh_hugetlb_folio plus = prep_and_add_allocated_folios to achieve the same goal but more simpler, right? > if (!folio) > break; > - free_huge_folio(folio); /* free it into the = hugepage allocator */ > + list_add(&folio->lru, &folio_list); > } > cond_resched(); > } > + > + if (!list_empty(&folio_list)) { > + /* Send list for bulk vmemmap optimization processing */ > + hugetlb_vmemmap_optimize_folios(h, &folio_list); > + > + list_for_each_entry_safe(folio, tmp_f, &folio_list, lru) = { > + free_huge_folio(folio); /* free it into the = hugepage allocator */ > + } > + } We could use prep_and_add_allocated_folios here. Thanks. > + > if (i =3D=3D h->max_huge_pages_node[nid]) > return; >=20 > --=20 > 2.34.1 >=20