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 X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B63BFC433ED for ; Thu, 29 Apr 2021 02:00:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B75161419 for ; Thu, 29 Apr 2021 02:00:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B75161419 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 198C06B006C; Wed, 28 Apr 2021 22:00:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 170456B006E; Wed, 28 Apr 2021 22:00:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0112F6B0070; Wed, 28 Apr 2021 22:00:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id D82EC6B006C for ; Wed, 28 Apr 2021 22:00:45 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 91BBB4428 for ; Thu, 29 Apr 2021 02:00:45 +0000 (UTC) X-FDA: 78083750850.07.60392C3 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf15.hostedemail.com (Postfix) with ESMTP id 2AB33A0003BF for ; Thu, 29 Apr 2021 02:00:39 +0000 (UTC) Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FVzDM1Xx1z16N0m; Thu, 29 Apr 2021 09:58:11 +0800 (CST) Received: from [10.174.176.174] (10.174.176.174) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Thu, 29 Apr 2021 10:00:34 +0800 Subject: Re: [PATCH 3/5] mm/huge_memory.c: add missing read-only THP checking in transparent_hugepage_enabled() To: Yang Shi CC: Andrew Morton , Zi Yan , , Matthew Wilcox , "Yang Shi" , , "Ralph Campbell" , Song Liu , "Kirill A. Shutemov" , Rik van Riel , Johannes Weiner , Minchan Kim , Linux Kernel Mailing List , Linux MM References: <20210427133214.2270207-1-linmiaohe@huawei.com> <20210427133214.2270207-4-linmiaohe@huawei.com> <1fa95721-2ae0-af5f-b2e4-cdb430ebc263@huawei.com> From: Miaohe Lin Message-ID: <18d8302c-3ff0-c508-2e8f-61d55bafe4fd@huawei.com> Date: Thu, 29 Apr 2021 10:00:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.174] X-CFilter-Loop: Reflected X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2AB33A0003BF X-Stat-Signature: txd99go8yiut1qrue34xk4yor1t76k4q Received-SPF: none (huawei.com>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=szxga04-in.huawei.com; client-ip=45.249.212.190 X-HE-DKIM-Result: none/none X-HE-Tag: 1619661639-198062 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 2021/4/29 0:21, Yang Shi wrote: > On Tue, Apr 27, 2021 at 7:06 PM Miaohe Lin wrote: >> >> On 2021/4/28 5:03, Yang Shi wrote: >>> On Tue, Apr 27, 2021 at 6:32 AM Miaohe Lin wrote: >>>> >>>> Since commit 99cb0dbd47a1 ("mm,thp: add read-only THP support for >>>> (non-shmem) FS"), read-only THP file mapping is supported. But it >>>> forgot to add checking for it in transparent_hugepage_enabled(). >>>> >>>> Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS") >>>> Signed-off-by: Miaohe Lin >>>> --- >>>> mm/huge_memory.c | 3 +++ >>>> 1 file changed, 3 insertions(+) >>>> >>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>>> index 76ca1eb2a223..aa22a0ae9894 100644 >>>> --- a/mm/huge_memory.c >>>> +++ b/mm/huge_memory.c >>>> @@ -74,6 +74,9 @@ bool transparent_hugepage_enabled(struct vm_area_struct *vma) >>>> return __transparent_hugepage_enabled(vma); >>>> if (vma_is_shmem(vma)) >>>> return shmem_huge_enabled(vma); >>>> + if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && vma->vm_file && >>>> + (vma->vm_flags & VM_DENYWRITE)) >>>> + return true; >>> >> >> Many thanks for your quick respond and Reviewed-by tag! >> >>> I don't think this change is correct. This function is used to >>> indicate if allocating THP is eligible for the VMAs or not showed by >>> smap. And currently readonly FS THP is collapsed by khugepaged only. >>> >>> So, you need check if the vma is suitable for khugepaged. Take a look >>> at what hugepage_vma_check() does. >>> >>> And, the new patch >>> (https://lore.kernel.org/linux-mm/20210406000930.3455850-1-cfijalkovich@google.com/) >>> relax the constraints for readonly FS THP, it might be already in -mm >>> tree, so you need adopt the new condition as well. >>> >> >> Many thanks for your comment. I referred to what hugepage_vma_check() does about >> Read-only file mappings when I came up this patch. But it seems I am miss something. > > Yes, you need do the below check for readonly FS THP too: > > if ((vm_flags & VM_NOHUGEPAGE) || > test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags)) > return false; > > This check is done separately for anonymous and shmem. It seems not > perfect to do it three times in a row. So I'd suggest extracting the > check into a common helper then call it at the top of > transparent_hugepage_enabled() . > > The helper also could replace the same check in > __transparent_hugepage_enabled() and shmem_huge_enabled(). > I see. Many thanks for detailed explanation and good suggestion! Will do it in v2. :) >> Take the new patch into account, the check for READ_ONLY_THP now should be: >> >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index 76ca1eb2a223..a46a558233b4 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -74,6 +74,10 @@ bool transparent_hugepage_enabled(struct vm_area_struct *vma) >> return __transparent_hugepage_enabled(vma); >> if (vma_is_shmem(vma)) >> return shmem_huge_enabled(vma); >> + if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && vma->vm_file && >> + !inode_is_open_for_write(vma->vm_file->f_inode) && >> + (vma->vm_flags & VM_EXEC)) >> + return true; >> >> return false; >> } >> >> Am I miss something about checking for READ_ONLY_THP case? Or READ_ONLY_THP case is ok >> but other case is missed? Could you please explain this more detailed for me? >> >> Many thanks! >> >>>> >>>> return false; >>>> } >>> >>>> -- >>>> 2.23.0 >>>> >>>> >>> >>> . >>> >> > . >