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 DEED5C433EF for ; Fri, 10 Jun 2022 07:20:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A1798D007F; Fri, 10 Jun 2022 03:20:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5515B8D0064; Fri, 10 Jun 2022 03:20:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 440168D007F; Fri, 10 Jun 2022 03:20:11 -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 355158D0064 for ; Fri, 10 Jun 2022 03:20:11 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EFC0633C2D for ; Fri, 10 Jun 2022 07:20:10 +0000 (UTC) X-FDA: 79561477380.23.3DD6296 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf15.hostedemail.com (Postfix) with ESMTP id B0577A0060 for ; Fri, 10 Jun 2022 07:20:09 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4LKC4p28G8zjXS8; Fri, 10 Jun 2022 15:19:06 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 10 Jun 2022 15:20:05 +0800 Subject: Re: [v3 PATCH 2/7] mm: thp: introduce transhuge_vma_size_ok() helper To: Yang Shi CC: , , , , , References: <20220606214414.736109-1-shy828301@gmail.com> <20220606214414.736109-3-shy828301@gmail.com> From: Miaohe Lin Message-ID: <8ba0f470-af80-1087-4361-eacbcbc52d90@huawei.com> Date: Fri, 10 Jun 2022 15:20:05 +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: <20220606214414.736109-3-shy828301@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654845610; a=rsa-sha256; cv=none; b=lNMlrIvNldYAYna6sLI063nuHpACm5dKrDNkyMdlef3ghmYw8JcIZapQYMeuSMxRuj9c9z PV0wB3YQhwu3iGWoeWF8vcKF1I3+i6dzLG+Gd51Nyt+fks/6Vjo8UgwYoPbYXT7hulZgIC KRt7Zg9KKx/9QoZrVPCNus/DpsEkt54= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf15.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654845610; 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; bh=HupencuJb2Gi1iLAUDc398+seiklEnaR+nQk6Bdsk3A=; b=TZwxYZfNOFO1b3ngjBx9RydaJY+W6IbKG4VrnHLp7pRkqRIQ5CrYztAq5P5O+my03PyoZ9 5XUFPoVlr4GJ7Pas05U/0YuH9fvAx0HYZabP3vqpeMUJwZsOk5oPu44tbUd4qQNbQGJ/Rj ITJ+Km4j9jEeVymlKjM7NBDHjhpquuY= X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: B0577A0060 Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf15.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com X-Stat-Signature: bug7s3n5p7547utdqa159jj9kbimmpqt X-HE-Tag: 1654845609-986231 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 2022/6/7 5:44, Yang Shi wrote: > There are couple of places that check whether the vma size is ok for > THP or not, they are open coded and duplicate, introduce > transhuge_vma_size_ok() helper to do the job. > > Signed-off-by: Yang Shi > --- > include/linux/huge_mm.h | 17 +++++++++++++++++ > mm/huge_memory.c | 5 +---- > mm/khugepaged.c | 12 ++++++------ > 3 files changed, 24 insertions(+), 10 deletions(-) > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index 648cb3ce7099..a8f61db47f2a 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -116,6 +116,18 @@ extern struct kobj_attribute shmem_enabled_attr; > > extern unsigned long transparent_hugepage_flags; > > +/* > + * The vma size has to be large enough to hold an aligned HPAGE_PMD_SIZE area. > + */ > +static inline bool transhuge_vma_size_ok(struct vm_area_struct *vma) > +{ > + if (round_up(vma->vm_start, HPAGE_PMD_SIZE) < > + (vma->vm_end & HPAGE_PMD_MASK)) > + return true; > + > + return false; > +} > + > static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, > unsigned long addr) > { > @@ -345,6 +357,11 @@ static inline bool transparent_hugepage_active(struct vm_area_struct *vma) > return false; > } > > +static inline bool transhuge_vma_size_ok(struct vm_area_struct *vma) > +{ > + return false; > +} > + > static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, > unsigned long addr) > { > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 48182c8fe151..36ada544e494 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -71,10 +71,7 @@ unsigned long huge_zero_pfn __read_mostly = ~0UL; > > bool transparent_hugepage_active(struct vm_area_struct *vma) > { > - /* The addr is used to check if the vma size fits */ > - unsigned long addr = (vma->vm_end & HPAGE_PMD_MASK) - HPAGE_PMD_SIZE; > - > - if (!transhuge_vma_suitable(vma, addr)) There is also pgoff check for file page in transhuge_vma_suitable. Is it ignored deliberately? > + if (!transhuge_vma_size_ok(vma)) > return false; > if (vma_is_anonymous(vma)) > return __transparent_hugepage_enabled(vma); > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 84b9cf4b9be9..d0f8020164fc 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -454,6 +454,9 @@ bool hugepage_vma_check(struct vm_area_struct *vma, > vma->vm_pgoff, HPAGE_PMD_NR)) > return false; > > + if (!transhuge_vma_size_ok(vma)) > + return false; > + > /* Enabled via shmem mount options or sysfs settings. */ > if (shmem_file(vma->vm_file)) > return shmem_huge_enabled(vma); > @@ -512,9 +515,7 @@ void khugepaged_enter_vma(struct vm_area_struct *vma, > unsigned long vm_flags) > { > if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags) && > - khugepaged_enabled() && > - (((vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK) < > - (vma->vm_end & HPAGE_PMD_MASK))) { > + khugepaged_enabled()) { > if (hugepage_vma_check(vma, vm_flags)) > __khugepaged_enter(vma->vm_mm); > } After this change, khugepaged_enter_vma is identical to khugepaged_enter. Should one of them be removed? Thanks! > @@ -2142,10 +2143,9 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, > progress++; > continue; > } > - hstart = (vma->vm_start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; > + > + hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE); > hend = vma->vm_end & HPAGE_PMD_MASK; > - if (hstart >= hend) > - goto skip; > if (khugepaged_scan.address > hend) > goto skip; > if (khugepaged_scan.address < hstart) >