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 49B23C4345F for ; Thu, 2 May 2024 17:27:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 944ED6B0095; Thu, 2 May 2024 13:27:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F5A86B0096; Thu, 2 May 2024 13:27:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76F846B0098; Thu, 2 May 2024 13:27:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 546E26B0095 for ; Thu, 2 May 2024 13:27:41 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 06602120790 for ; Thu, 2 May 2024 17:27:41 +0000 (UTC) X-FDA: 82074137922.28.6881F22 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf02.hostedemail.com (Postfix) with ESMTP id 4983380012 for ; Thu, 2 May 2024 17:27:38 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uy+BbCbQ; spf=pass (imf02.hostedemail.com: domain of fvdl@google.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714670858; 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=KUNTNSxf5jFZNiSIENiFHEDs4SL26oCzRgNOWpdMUDI=; b=raWftBhlRZ0pSCQUfOYyomSd+g7EgJsT2szrZ6fOOf6b/1DqAKXMAgXURT4Lzd0MLr8S1Q FcQYPQDTU1Zd+ipOb6knnaHW1xEC4gPE93ycx9IUcaC8TCiHZ4gF90HASiaOdzAZLvCIeY jaCdIFSlNmnSNGGZMSLAzhhYDyv3uu0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uy+BbCbQ; spf=pass (imf02.hostedemail.com: domain of fvdl@google.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714670858; a=rsa-sha256; cv=none; b=AQlQb/EAmOH3rlHoj0YBQwXxScKLJH2Dcyr6YoagFq4BIgxcbbs7E1HQyw7mJBSnLRXc93 yQRtnCapMfZe9cc2ULfE1ISYWFaD0lLQt/LRTuWRDDHDaOCUwmi2/vyoWciE+2/8Ki9wtc grJtyQPRtAI3qJrXe3fNs9sblnzTqbg= Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4db24342894so2920840e0c.0 for ; Thu, 02 May 2024 10:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1714670857; x=1715275657; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KUNTNSxf5jFZNiSIENiFHEDs4SL26oCzRgNOWpdMUDI=; b=uy+BbCbQr0sANwG7Slp7VFGmrzR98eEHOOv1YiJ53zFNyTGJgM971Zq61ecyd2U4Cd mgvAYNY54MIgHfrFocAO2j+NTUuBiPLip22Prh010ge7iS5TUK6So7ODWcyuldeCfPOM fUimHmGXOH+0gjSVind4kPE/hm36Br2EL/fLc+01p33j7CY0iS9IOnJzAvL01IAUQmO8 nPEj27pgt41kjzuYyJARKimWiTXgBHdSx+lJMf7h8CjvdQIiH78qqknacVi2RTE3stLF 2+gXRONMb2iroBgBnSl4ufiGH+jMWBLEDgXaXnnvzorzeXk91omECKl553XvPIXWJ9wH nTfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714670857; x=1715275657; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KUNTNSxf5jFZNiSIENiFHEDs4SL26oCzRgNOWpdMUDI=; b=f7SY9bnK6naKCdL1UR+Ni3ZrY40rX9oRZqUKsBBycmyjwcMDDAJ04Kvoj4XUFw8wPK zxM2mw4/ncpg0baowuU5WoJHKK2doOyWTHtj1pooReAQvtupO7SdVy6bd2vM0Pm2sXhk +PGSgYQ8nmRMl2AKhopn5mcRY2i3WAVYuAuoZfS7N80WSyFqcSghnXbZp1uB+/Wo6jf7 P9XMfSzIrMlOX9pRH1u8Zl4788yAqG9DjhcQRTzJC0RimkyJdAbp9kI7e2InsOD41Jiu Zr+Qr/8OqViKT6dwsPU3KjVO0jiWYvX3nj848CoAKxKbxTcMIM4RAyKMqRAZ77UeS9aQ GA0w== X-Gm-Message-State: AOJu0YyGY0Tb1HwOEwY1AsNRBVnvYpsLt0UmAe0V0Y2/pbAoJ6qt67JL zM+KaxD/F8S2fvpn991mPjfyEU1pjDqxsWWzzIN1mpQbCWAg1SIg+A/uYW3l8XWo+k6V29/uh4s uGcHbIn5SdGEM2jwRPTpY6u+IByx98JftO00oa9lktrkayibyRQ== X-Google-Smtp-Source: AGHT+IETS7W+0UiiCxMHSkWyqgFGBmGn1czdfEi9XQryWuBAq1ubtfmmYxw+yY12+x/JSJ5/L7jKzJduZF8+8/1rnI4= X-Received: by 2002:a05:6122:4319:b0:4db:223b:1c0a with SMTP id cp25-20020a056122431900b004db223b1c0amr408732vkb.11.1714670857208; Thu, 02 May 2024 10:27:37 -0700 (PDT) MIME-Version: 1.0 References: <20240430161437.2100295-1-fvdl@google.com> In-Reply-To: From: Frank van der Linden Date: Thu, 2 May 2024 10:27:25 -0700 Message-ID: Subject: Re: [PATCH] mm/hugetlb: align cma on allocation order, not demotion order To: David Hildenbrand Cc: linux-mm@kvack.org, muchun.song@linux.dev, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Roman Gushchin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9t81d16i37h7pw5poq1dyndirrfrxmmz X-Rspamd-Queue-Id: 4983380012 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1714670858-360474 X-HE-Meta: U2FsdGVkX1+1k/irErPsWKZgu3JwcSQ5IZ/Wy2ERWUkZR6Ip3U5qlzyA23h7VvP6e2y7/RTxC5azGSqLfzhlxsm8zexJ5q11LFgBhRf19N11xG2vlGZVYQ0ex7b0S5Tvm+z1DqZQxaTmP+1iUmodGM2X/tpTyM55/oOluMTuDnD5plQ0+S2B90RBu9/Csr2IXh3WizyP/1KbcIe649pmUcm8BrsLmJG4v4u6GHiv9W7A/EDcZnMGHuK4oKm/+8+aeTTB2u4QFjOHS1sNlIhl19olZGMreKNIGe4O6k1KvrbqndRvM6+TsIlAkqRJywHW+REFZc5qk3LRdsOPX6aOglcKV8NXYEBXgVhNS2W7bFrvFnykQs9pGTyU7+NCJOHJJryaztAWTDIocxMn7XDCMlA+1TZt/GGtauxbduPWb18Rbwfvrr8O6n+/UQ6ULE9gekfrPBdbt7ellj15ErS70CfQ2M78Z+Plb9n8mgW/dhJ4teSNU/EDs6iiNkpiWgib8HCJ7l46OBVYnjBYhrB1UTUxoJXtUGOYOyata8vmSHcuxfYa/vKWeiY3WIRO146zEmzEMIPMtKuBUAIGvRu2Uj3if1tTv8igNjyjJZwFqyPu3GIUSyhcl6gkBKI7vzjiX5z1fG8rcBUocpBjWBlegXzubyPJchbCygbFqqcJe0pmPMCC37IYdtxE5t3r9YyeM6/DBwJbycFOixOGr+ByXry8r/bD/pRku3KMkMDfP1LrYRW3rPDSsxIeExu35uqozl+RjAfnN3VGl/0rQXLkmn1OIho60hypPFYBWyGSw828gGc9P2ytk7G527wLPDiepMsSO0cxMDe8RN7KJWnph9xMDRf5pT+L81BHQHSagLJXSdmpRdqXB1MifW+BLh0nA9T1DkI3m5/aEmtk74nMKTC1oQBipXA7RiycTlazho/IF0s14iyhOrTuJwiAWJlVIs0FYYfhOYoLZ+OByl1 TP7fh6mq q5EdDogf3PvktbYBO171AFnrbHEyQbaEkEdlRK82L+V6xNHBlDPKRq53fJS4Tbv9LQY3iOB+Q8THwJjHbD/ul729E6PEfZK4QfyI4XwIADcin9avuTelUbaAQ/Zta48S5830Inb/iNRHWZVVHExfnoT2Se0Yr+zWCiJpI7L7w8btVv0LGD8Lr9NUZXxdmvurM8o8SQWAB3XetQfvO203+W9dHSFStQDzdEvqkpU2HyUTFi/p2CWCwKwE6k7m12/bL6zfpXv3TMoMBmbKvgRnaFMLZMw== 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 Thu, May 2, 2024 at 6:15=E2=80=AFAM David Hildenbrand = wrote: > > On 30.04.24 18:14, Frank van der Linden wrote: > > Align the CMA area for hugetlb gigantic pages to their size, not the > > size that they can be demoted to. Otherwise there might be misaligned > > sections at the start and end of the CMA area that will never be used > > for hugetlb page allocations. > > > > Signed-off-by: Frank van der Linden > > Cc: Roman Gushchin > > Fixes: a01f43901cfb ("hugetlb: be sure to free demoted CMA pages to CMA= ") > > --- > > mm/hugetlb.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 5dc3f5ea3a2e..cfe7b025c576 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -7794,7 +7794,7 @@ void __init hugetlb_cma_reserve(int order) > > * huge page demotion. > > */ > > res =3D cma_declare_contiguous_nid(0, size, 0, > > - PAGE_SIZE << HUGETLB_PAGE_ORDER, > > + PAGE_SIZE << order, > > HUGETLB_PAGE_ORDER, false, name, > > &hugetlb_cma[nid], nid); > > if (res) { > > I was wondering how that worked when reviewing your other patch. > Wondering why we never got a BUG report, maybe we were always lucky > about the alignment we actually got? I think this issue was probably masked by the hugetlb allocator falling back to direct alloc_contig_pages allocation if cma_alloc fails. So if you're not under memory pressure, the failure to allocate from the misaligned areas might not have been noticed. I noticed it, because I was working with change I made: a flag that prevents the fallback to straight alloc_contig_pages, as that behavior may not be desired - you don't want to potentially eat in to non-movable space that the kernel needs, it might be better to fail if there's no CMA available. > > We round up size to PAGE_SIZE << order, so that's the alignment we need. > > Reviewed-by: David Hildenbrand Thanks!