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 0C770C433EF for ; Fri, 10 Jun 2022 16:48:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 428228D00CA; Fri, 10 Jun 2022 12:48:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D7628D00C1; Fri, 10 Jun 2022 12:48:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 278468D00CA; Fri, 10 Jun 2022 12:48:11 -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 14FEB8D00C1 for ; Fri, 10 Jun 2022 12:48:11 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BF6302056E for ; Fri, 10 Jun 2022 16:48:10 +0000 (UTC) X-FDA: 79562908740.29.280B644 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf04.hostedemail.com (Postfix) with ESMTP id AE9FF40089 for ; Fri, 10 Jun 2022 16:48:07 +0000 (UTC) Received: by mail-pg1-f178.google.com with SMTP id d129so25271271pgc.9 for ; Fri, 10 Jun 2022 09:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8vFyBrdxSbkI+mfhKuuYNpkHpuCxKZS4GtlQHUPNgHw=; b=KMiA0J2I/vzgsnbe9ot1ANdEAoLdqlcKhBXmL++rYc3bBaizGMuqjJ19IQ/+G2sUis kkY8drJvJC0FpP69oNtGTR+hbX/ZxE47a3/wmuTUzB3W4T2z3Ud4t4aZKZcWN9KnXj1f 04AN1IOWAxPxMXbRzC5dfe8LR8axbXznLnC3vpQ0Q9uMAsd8mEeiDFbl8d7/Srdv01I1 MQQQJ30dm8nK/kGGONxOLJ+9Dx48+QyFsg3ckpHg0JfXhw3YiCT44kGWOoISjgE06fDH pSPzu8sHlpfIlMlS+mECMTy7Lfk9rfTUPd4FFucKwLqVxe5WU49dsBXtG6H+VdtKC+FL QVqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8vFyBrdxSbkI+mfhKuuYNpkHpuCxKZS4GtlQHUPNgHw=; b=V1cbz9QhTtwQJLDvwPdrM2fwBPw5u4W3y5Oehh8ksZ0sS+FGe3IrTQMe2BqAc5K+Pl s3koTSwNLUTWKR3Oh/d9D+1Q1jWqRh2atKwN8R005UxlDyguJLkgJKbsMzJETOIUGVEj V3O7DVp6c+UzwXr+xPq2RuNPe2HkdlKewa/KWfOJXVCmCNI1VL74MTL0wvrM9cELoMB0 gHU1t22HL8Tc0HFWWvYMkmPXYLPbFbKNUl6MD6nmFKcR0DeFWQxN7wwxuKTAyVTNyP2M +fGCgRhHCuNy0v0HwH2i37VkGKWAiR6Cv4WEdFNfFzwiVC9yrXtmD/KhkYeJPAgNOZnl 5xQg== X-Gm-Message-State: AOAM530XumKoJHXRgaHZzR9EuMHyamK1Wbjda9gj2cPFwS/o2cuxTaJn d7/q3eSICacSbpBVmy7jDxqY1QGszjdCmH4FpQw= X-Google-Smtp-Source: ABdhPJy7BMJPOVUSEhhWXJXOrQPJJMTAm54bVzXOOhDzOedG/6evZ3PbNk2seLRSXaruNMI5Tb+dEQ1xhFl9/fmlnbA= X-Received: by 2002:a05:6a02:184:b0:3fc:3b43:e5da with SMTP id bj4-20020a056a02018400b003fc3b43e5damr39448807pgb.587.1654879686708; Fri, 10 Jun 2022 09:48:06 -0700 (PDT) MIME-Version: 1.0 References: <20220606214414.736109-1-shy828301@gmail.com> <20220606214414.736109-3-shy828301@gmail.com> <8ba0f470-af80-1087-4361-eacbcbc52d90@huawei.com> In-Reply-To: <8ba0f470-af80-1087-4361-eacbcbc52d90@huawei.com> From: Yang Shi Date: Fri, 10 Jun 2022 09:47:54 -0700 Message-ID: Subject: Re: [v3 PATCH 2/7] mm: thp: introduce transhuge_vma_size_ok() helper To: Miaohe Lin Cc: Linux MM , Linux Kernel Mailing List , Vlastimil Babka , "Kirill A. Shutemov" , Matthew Wilcox , Andrew Morton Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654879687; a=rsa-sha256; cv=none; b=WHd5IOVH+8hWDARz29Z3buRBu0xZyepIjFkPPDPqRY3ohwXnGjVXYPpIAFzdKlNnAR8K/5 MQxSy/ejboc8SnI/jPkGMCbHETb0pmULzHRkKUzL7zjonf3Jf8ICdwPSeSU2cetpGu+NfY 3lQ91Zb0kQKR4cwntqPDfYWtnbpmouc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KMiA0J2I; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654879687; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8vFyBrdxSbkI+mfhKuuYNpkHpuCxKZS4GtlQHUPNgHw=; b=ciotbt0s/vP26kBZJiqjGj/2hxbGWMK+bRiBYFf1DeYA7iyIBC+D6h4xRb3tsyS+bgUR6W bliVw1XGW0dZWP9g+vepAmEEBeghetOs6n/O3Pzyyqi//7BwwuJIty4rPjY/nfGvIlZg34 jzhMhGyr9ILTlqWO18sgut1FVepgB1A= X-Stat-Signature: 5tip4hp3gtyfmp77skan4dcgnc5w6sgt X-Rspamd-Queue-Id: AE9FF40089 X-Rspam-User: X-Rspamd-Server: rspam10 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KMiA0J2I; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-HE-Tag: 1654879687-378319 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 Fri, Jun 10, 2022 at 12:20 AM Miaohe Lin wrote: > > 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? This has been discussed in the previous threads. The following removal of transparent_hugepage_active() will restore the behavior. > > > + 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 for catching this. Although the later patch will make them slightly different (khugepaged_enter() won't check hugepage flag anymore), but the only user of khugepaged_enter() is page fault, and it seems not worth keeping both. Will remove khugepaged_enter() in the next version. > > 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) > > >