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 54F4EECE577 for ; Mon, 9 Sep 2024 01:22:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C45F16B00F7; Sun, 8 Sep 2024 21:22:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF5F86B00F8; Sun, 8 Sep 2024 21:22:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABD916B00F9; Sun, 8 Sep 2024 21:22:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8D18E6B00F7 for ; Sun, 8 Sep 2024 21:22:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 39CAA140A89 for ; Mon, 9 Sep 2024 01:22:24 +0000 (UTC) X-FDA: 82543449408.27.D25BD53 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf02.hostedemail.com (Postfix) with ESMTP id 2D6CB80007 for ; Mon, 9 Sep 2024 01:22:20 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=kdKOaBvc; spf=pass (imf02.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725844892; 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=80WCtbj8jM9c9NM49mgaWLX8tfT9emUWMYbHRmGHerc=; b=nVw0L9NljST6kPIMNnoavmfOXnn2JUfF3Pt+neb6CWRpDUnZb7Uk6BA84GNI5Qsb2/Ps5E mAlCrGNMLXsSwcygaxY+ThmqZsFyOstfy6TCt9iCjdMkU7XXq7zAWwTCZSxjK3rgy5yWAQ vjgG/EhWrUvhGF5KLaZdnmHsJkpwb4A= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=kdKOaBvc; spf=pass (imf02.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725844892; a=rsa-sha256; cv=none; b=Iu7uUaMa92QpwzIAr6RaHXdLRmlIaCzb5kBkLxO0L7y6uxSGNqAAjRcIr3jAGMbbrtQI4/ 4pc8xQz7Q6xhOfqcTcLV/KEALr3bcOYeBCI1Xg/eScaO45i2zUsrQf4zkKyAE3DoteqaVe XcSeM1v6xSC+WIU+Zrs9uoUzKB/9zvA= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1725844938; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=80WCtbj8jM9c9NM49mgaWLX8tfT9emUWMYbHRmGHerc=; b=kdKOaBvchJDS8ioGkwAQsyLXEo2DDXnMPsaTlagyUzxZQJyHU1KRSOVtRHHyOlTNHx1iaxy5B3o5HwlXav80hLiKdurvEd+9pz8Gg829J9gcZTT5uiLD7saD9WddhRfm3MJs6AIXzjaH6Tl+CWtre+HReNsLY3LwkOV988DHh+c= Received: from 30.74.144.122(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WEVg-uL_1725844936) by smtp.aliyun-inc.com; Mon, 09 Sep 2024 09:22:17 +0800 Message-ID: Date: Mon, 9 Sep 2024 09:22:15 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: shmem: fix khugepaged activation policy for shmem To: Ryan Roberts , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, 21cnbao@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <7c796904528e21152ba5aa639e963e0ae45b7040.1725600217.git.baolin.wang@linux.alibaba.com> <58cf63c1-25e5-4958-96cb-a9d65390ca3e@arm.com> From: Baolin Wang In-Reply-To: <58cf63c1-25e5-4958-96cb-a9d65390ca3e@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 2D6CB80007 X-Stat-Signature: bekf5qndcbwe1nqjymaptb8t9yrum4ib X-HE-Tag: 1725844940-285540 X-HE-Meta: U2FsdGVkX1/tzLmVPAdG98pEVAMLdwdki4XQFDRP2LK1qcEUfyL9z6/05yPZmIEldmx5bqpqKk/oU1uADrtLZWM9F0Z3tTPMkC8w4jfkA/kdHll+1UQcJ3B4xyRrKpkNurJIru8dmr/uqfVAAtSUPR2IxXwtFWbsqC7hR00RvXWLgSv8Uf6Nx7pY5gciW0zyq7SaWAPY013JZYroCdii2jGHJIPITn7oOA80heEzOY/KWkqdPHnxqqhyQuGeiWzanoQEMNVlHKYRGDDGjpH+I+yJYP/Wwhlsf+NaKXXQ1at0RZN3tOTIRt/kGlSnroTjcl3kJkaxLI9Md8QzIojjnlvSh6BuFYRDpUu2ewFYBP4fsKPxpHyMx13x4ko63Om+Oe5zFNrF1f91CyLgWiBQJVJZWJkGV7KSoGuQtEmYJb/JicrGZ+JzOyKewJ3cppszQeGm9WxL91wK+5utpLTRLEq62N03eyaz0vmF6OQnw+vHzc9rhooRoJ6dZAmlrrB7G2vubEGz4zQjfgKphMFLLvpCAcFOuTlUMp3EfkSnTksznuJCb5XNuIyA4hCkgR5Y4vEHFTI92T1VJNfcxCVudNsO28FSxv8iUwyeeJMig/DgWJqD5MC9Jnq3jDEwe0nff9Y8KJqpSZinkmRuz3oyZdDGIOjo2lburZx+TJ65ZyBjPtpAnfmQd3makEWFgCRkyYv3UOdlfQixhUWiyAcJm9fYCJ7XLuT5eNUTJJzhUFId8WHEQW+lRR00JgXyAHePxwA+9pyqP2UqvlpVnZKfe8O5quUTojkikr4dZVBnp3vX7rMKrA39fy2LydzR6zhtPgHijXzAJ1BZR6IMYz1F64ZDFj6EED73nIWPe23Z+OpBo6xTyNA2X1P/rRxGitVbaRQA77Qjs2c8gaXTGBLVPjWuaDeP4S4TBPN45pkOlWdnzq29fqCmFNxLmmo3FeksozZ6iQ++BsKMo/KSppQ 7j2v0ceH Bzb/ExrP9F66IEHyvbSEWJTVexb4wegFtMjgAi/Uu2+rby+Y6kP8uVk9FTkL2/zAjR5QWR0oKOiyEGk6EUJ5HMQakSJJFVloVqEIK/hkqB7V/4kCzK43gXJJM6Zvr1ylBUzpAhJ8U8F81lnRMAWVwvaeNOL2Zl9DI+HL6JKMg4KyEoAcNkNkBnXrcj5GfEy5M0eMnVCmaNL6BeKyLOtOW8t+acchuTnbrBth6+AiMUxqR/DSkrw1LDOoSIoBMmxoNFtb1XhLmxj9quJ/jy6miVlGwKzoZbmrP9SRoieWWVo5MqVFcdRzB4AH9xEHY1XvtWmKQilvFUzVlRxlcmzNvpggd0jMn3E5/f2/V9W6gm/6TegL+n44FFSor3WXR8OyVqLHRgmd0qFdqsrFlWw9b3bWF8J4b7UwcXTVntoX/9xlDyKoyu4V3GXt/G8mrkUyyNaW6WwV10qmopxw= 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 2024/9/6 16:55, Ryan Roberts wrote: > On 06/09/2024 06:28, Baolin Wang wrote: >> Shmem has a separate interface (different from anonymous pages) to control >> huge page allocation, that means shmem THP can be enabled while anonymous >> THP is disabled. However, in this case, khugepaged will not start to collapse >> shmem THP, which is unreasonable. >> >> To fix this issue, we should call start_stop_khugepaged() to activate or >> deactivate the khugepaged thread when setting shmem mTHP interfaces. >> Moreover, add a new helper shmem_hpage_pmd_enabled() to help to check >> whether shmem THP is enabled, which will determine if khugepaged should >> be activated. >> >> Reported-by: Ryan Roberts >> Signed-off-by: Baolin Wang >> --- >> Hi Ryan, >> >> I remember we discussed the shmem khugepaged activation issue before, but >> I haven’t seen any follow-up patches to fix it. Recently, I am trying to >> fix the shmem mTHP collapse issue in the series [1], and I also addressed >> this activation issue. Please correct me if you have a better idea. Thanks. > > Thanks for for sorting this - it looks like a good approach to me! Just a couple > of nits. Regardless: > > Reviewed-by: Ryan Roberts Thanks for reviewing. > >> >> [1] https://lore.kernel.org/all/cover.1724140601.git.baolin.wang@linux.alibaba.com/T/#u >> --- >> include/linux/shmem_fs.h | 6 ++++++ >> mm/khugepaged.c | 2 ++ >> mm/shmem.c | 29 +++++++++++++++++++++++++++-- >> 3 files changed, 35 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h >> index 515a9a6a3c6f..ee6635052383 100644 >> --- a/include/linux/shmem_fs.h >> +++ b/include/linux/shmem_fs.h >> @@ -114,6 +114,7 @@ int shmem_unuse(unsigned int type); >> unsigned long shmem_allowable_huge_orders(struct inode *inode, >> struct vm_area_struct *vma, pgoff_t index, >> loff_t write_end, bool shmem_huge_force); >> +bool shmem_hpage_pmd_enabled(void); >> #else >> static inline unsigned long shmem_allowable_huge_orders(struct inode *inode, >> struct vm_area_struct *vma, pgoff_t index, >> @@ -121,6 +122,11 @@ static inline unsigned long shmem_allowable_huge_orders(struct inode *inode, >> { >> return 0; >> } >> + >> +static inline bool shmem_hpage_pmd_enabled(void) >> +{ >> + return false; >> +} >> #endif >> >> #ifdef CONFIG_SHMEM >> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >> index f9c39898eaff..caf10096d4d1 100644 >> --- a/mm/khugepaged.c >> +++ b/mm/khugepaged.c >> @@ -430,6 +430,8 @@ static bool hugepage_pmd_enabled(void) >> if (test_bit(PMD_ORDER, &huge_anon_orders_inherit) && >> hugepage_global_enabled()) >> return true; >> + if (shmem_hpage_pmd_enabled()) >> + return true; > > nit: There is a comment at the top of this function, perhaps that could be > extended to cover shmem too? Sure. How about the following changes? diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 945c0f2aff81..b0ac46ae561b 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -416,9 +416,11 @@ static inline int hpage_collapse_test_exit_or_disable(struct mm_struct *mm) static bool hugepage_pmd_enabled(void) { /* - * We cover both the anon and the file-backed case here; file-backed + * We cover the anon, shmem and the file-backed case here; file-backed * hugepages, when configured in, are determined by the global control. * Anon pmd-sized hugepages are determined by the pmd-size control. + * Shmem pmd-sized hugepages are also determined by its pmd-size control, + * except when the global shmem_huge is set to SHMEM_HUGE_DENY. */ if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && hugepage_global_enabled()) >> return false; >> } >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index 74f093d88c78..d7c342ae2b37 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -1653,6 +1653,23 @@ static gfp_t limit_gfp_mask(gfp_t huge_gfp, gfp_t limit_gfp) >> } >> >> #ifdef CONFIG_TRANSPARENT_HUGEPAGE >> +bool shmem_hpage_pmd_enabled(void) >> +{ >> + if (shmem_huge == SHMEM_HUGE_DENY) >> + return false; >> + if (test_bit(HPAGE_PMD_ORDER, &huge_shmem_orders_always)) > > question: When is it correct to use HPAGE_PMD_ORDER vs PMD_ORDER? I tend to use > PMD_ORDER (in hugepage_pmd_enabled() for example). In shmem, the HPAGE_PMD_* related macros are all controlled by CONFIG_TRANSPARENT_HUGEPAGE, and at this point, HPAGE_PMD_ORDER and PMD_ORDER are equal. I would like to keep consistency in the shmem code by using the HPAGE_PMD_* related macros.