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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C992C433F5 for ; Sun, 10 Oct 2021 22:43:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DCFC360F14 for ; Sun, 10 Oct 2021 22:43:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DCFC360F14 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 6722E6B006C; Sun, 10 Oct 2021 18:43:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 621726B0072; Sun, 10 Oct 2021 18:43:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E988900002; Sun, 10 Oct 2021 18:43:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id 407966B006C for ; Sun, 10 Oct 2021 18:43:57 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id ECFA1180889AE for ; Sun, 10 Oct 2021 22:43:56 +0000 (UTC) X-FDA: 78682006872.31.DE84DDC Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by imf01.hostedemail.com (Postfix) with ESMTP id B600850803E6 for ; Sun, 10 Oct 2021 22:43:56 +0000 (UTC) Received: by mail-pg1-f181.google.com with SMTP id s11so9005345pgr.11 for ; Sun, 10 Oct 2021 15:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=wIBUW6zc6MUbXhHNaYoyVQ0gurfpKZ2/JrmRwbRJyjw=; b=Cq3SX6S5HlMNcDmorjSLbAWhkIOGV1dZn6r/k2GUH4TzkYiBXzAr2jhidjKet5xBGP Q6KXRzwqvatmTMzuy7LjqSUZUM2rjRekZ1JtSfsAvbV67uAuFXpqXjr5QZf0Tr8Y4rL+ hAj1rsokigc3Y2l3z8ieVfpZ70nqwmErdxfbO43WoJYVxnF459Fh1a+dgqW9ybvuKKGg G9Mwgdq4gma9bs612jYAQXB5IEluHUGQ/OqxbZt9nMCgH9jdUM2QtWQ5I8+IuBhy3n0s eheA4hU2iSTpnvL8aqYgJZZirj4/GHdYYa383MSpHuQfPkf/AfHknETN1giEPqKrv0E2 H77Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=wIBUW6zc6MUbXhHNaYoyVQ0gurfpKZ2/JrmRwbRJyjw=; b=Sx8bUwZmZ2hV9wjc+fTKkXNFhj8k7v3964caWfipBnA+56Pwb/BfhDH1p3X2PnbbEL hI4zexfqar9nbA2nfIR1t6IFWz0O5VrGZ93eqWKKOc5FnCPItJGjIhnMhvTvu0yDgsPf 9+9tXeD5UoZBMzlIt0uWSIC83EvkZbo+45kii6TWQH1Pu2cHDowmuEKzwyq5csrYJ5qm YkAPKvmIMRg0qrJWOYtc09/Ujzi0CIhxHJA5RqCCRwt1I8VUIzjTO3pV8Eef7Zz2JIER txHbb1fyAH93PPo1k2Pi2l8Si0ynbjJy40t/tCarDH0vLmr4Zoh7BH2HqEJziOTY7jwE pDhA== X-Gm-Message-State: AOAM530bk0I0tcd+Kw6pY8X5p4ZxmUCIqTIvH39aVhP/+zKTcN1pbGUR hqcK4xlM7uwbGDseA9zNouUe2A== X-Google-Smtp-Source: ABdhPJyk2OEzkPPtqpWI6h3nLJiITXPlStEa+F4iRzbceJ+h5AtvReQT3QJszcRIt6AXfWgMCiUhmA== X-Received: by 2002:a63:4f:: with SMTP id 76mr15353398pga.457.1633905835385; Sun, 10 Oct 2021 15:43:55 -0700 (PDT) Received: from [2620:15c:17:3:3280:1d46:7d55:1fbb] ([2620:15c:17:3:3280:1d46:7d55:1fbb]) by smtp.gmail.com with ESMTPSA id z11sm5398218pfk.204.2021.10.10.15.43.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Oct 2021 15:43:54 -0700 (PDT) Date: Sun, 10 Oct 2021 15:43:53 -0700 (PDT) From: David Rientjes To: Hao Peng cc: "Kirill A. Shutemov" , David Hildenbrand , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm/huge_memory.c: disable THP with large THP size on small present memory In-Reply-To: Message-ID: References: <20211008095123.73b4bubwrpdj6tuz@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B600850803E6 X-Stat-Signature: 3kh7djuo3jkeowj14nkejqnukqy6wb3i Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Cq3SX6S5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of rientjes@google.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=rientjes@google.com X-HE-Tag: 1633905836-78437 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: On Sat, 9 Oct 2021, Hao Peng wrote: > > > After setting the page size to 64k on ARM64, the supported huge page > > > size is 512M and 1TB. Therefore, if the thp is enabled, the size > > > of the thp is 512M. But if THP is enabled, min_free_kbytes will > > > be recalculated. At this time, min_free_kbytes is calculated based > > > on the size of THP. > > > > > > On an arm64 server with 64G memory, the page size is 64k, with thp > > > enabled. > > > cat /proc/sys/vm/min_free_kbytes > > > 3335104 > > > > > > Therefore, when judging whether to enable THP by default, consider > > > the size of thp. > > > > > > V2: title suggested by David Hildenbrand > > > > > > Signed-off-by: Peng Hao > > > --- > > > mm/huge_memory.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > > index 5e9ef0fc261e..03c7f571b3ae 100644 > > > --- a/mm/huge_memory.c > > > +++ b/mm/huge_memory.c > > > @@ -437,7 +437,7 @@ static int __init hugepage_init(void) > > > * where the extra memory used could hurt more than TLB overhead > > > * is likely to save. The admin can still enable it through /sys. > > > */ > > > - if (totalram_pages() < (512 << (20 - PAGE_SHIFT))) { > > > + if (totalram_pages() < (512 << (HPAGE_PMD_SHIFT - PAGE_SHIFT))) { > > > > On x86-64 HPAGE_PMD_SHIFT is 21, so you double the amount of memory > > required to enabled THP by default. It doesn't seem to be the intent of > > the patch. > > > > What about something like > > > > if (totalram_pages() < 256 * HPAGE_PMD_NR) > > > > ? > > > I think that setting the threshold to 512M here is also a rough > estimate. If it is 512M > of memory and 2M of THP is used, there are only 256 pages in total. > This is actually > too small. So does this mean that the original intent of the patch is what you proposed? It's not discussed in the changelog so it's unclear. The "extra memory used could hurt more..." statement in the comment depends on other system-wide settings like max_ptes_none and whether you default to faulting hugepages if eligible. There are scenarios where there is no extra memory used, so I think the intent is for sane default behavior and, as you mention, it can always be enabled at runtime as well. By using 64KB native page sizes on small memory capacity systems, you're already opting into this memory bloat. If we are trying to avoid memory bloat then we likely shouldn't be defaulting max_ptes_none to 511 either and that would be a bigger consideration than a minimum memory capacity to enable thp. Or maybe you are questioning the adjustment to min_free_kbytes and whether that is rational or not for small machine sizes (but large page sizes). > In addition, THP is disabled by default, but you can also enable THP > dynamically. > Thanks.