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 83640C433EF for ; Wed, 18 May 2022 18:45:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D54D66B0072; Wed, 18 May 2022 14:45:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D05EB6B0073; Wed, 18 May 2022 14:45:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7F326B0074; Wed, 18 May 2022 14:45:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A2D646B0072 for ; Wed, 18 May 2022 14:45:28 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 798BE31A31 for ; Wed, 18 May 2022 18:45:28 +0000 (UTC) X-FDA: 79479741936.14.3D16D64 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf11.hostedemail.com (Postfix) with ESMTP id E200A400D8 for ; Wed, 18 May 2022 18:45:21 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id n8so2629060plh.1 for ; Wed, 18 May 2022 11:45:27 -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=3aLqFCIHlaNtUXWSW3P8CFFA9P/K5XYG2miYLAiW2do=; b=HVmMMT3XA+R82BVVebbL3V1VL1hVNV4JQjaKrHVXG2G/pqLeyfXZLvuP1YNX2AZ0UC R5z/1VtX4ldo8b8foPJUcuBbUwDszj/g46L4uZUUIZV1WFnF6EDscnXCVIlKYvwwhJ7E 1CPNzSxfDKIDg0owcBKQB5j7ZUtVANv1hfO9FNN3D8veokgta/6g4i2rr3JONTBpeCIg Yz44NGLUtovLClODpFUBGm6RegbrczWncE2ugf8jx5l+TUmJc3fcIBIi8vpPJMkiHXIf HtC62oe5MDlN0IbvkhTqliYxEaxh/5mY9WgOpwv0evorU94zuv8au5vbiP9AkM5A/zVQ eVnA== 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=3aLqFCIHlaNtUXWSW3P8CFFA9P/K5XYG2miYLAiW2do=; b=RDw/gkNUSbNWeqU6DcP9VK2h9NeCNyo8ewimlrggW0KmCv9ATAffYmyJmyiiKfoUt3 gNR7LtAAlxj4VVDE71lZufX17Z2qx7rF1nSbFcGOSCi1LtzPub37qf8hydp36je66tM+ DmdWb+px11Tk//voqZGzBGwFa05ARErGVDgUX4848qigpp5GXfZg3BW1g36lnbpjeBwV DdsY7Kf6PRjYgbUgKJiRW1StN3VBKy9hv3jT+RzpoXyu1d5S1CT4ECb97bibisOPftea Vq0fyfdEk16NdDlqCRuPzA20M9shlxxHYs9Bob6VFmt8ML+P4uSkkjGGulONi0v9LhWD zdwQ== X-Gm-Message-State: AOAM533eAQs3oCntSP1kIG0u2+wBq5z1txQAOXEtH14wtoi7uaXiJTxk 2FRs66h/SEpTtqST6R2YHaswdf/ZR9UIC+yEkk8Ru9oT X-Google-Smtp-Source: ABdhPJwZqBtopqsb1FdAQ1j8MWk0bfzi6/ffMW6kYKfUpos84fkjsZ2ZlxbQyQUbjLgCTmCSe4KgsxwjnmEYNL2ajmU= X-Received: by 2002:a17:90a:de15:b0:1df:63dd:9cfc with SMTP id m21-20020a17090ade1500b001df63dd9cfcmr823429pjv.200.1652899526990; Wed, 18 May 2022 11:45:26 -0700 (PDT) MIME-Version: 1.0 References: <20220513191705.457775-1-shy828301@gmail.com> In-Reply-To: From: Yang Shi Date: Wed, 18 May 2022 11:45:14 -0700 Message-ID: Subject: Re: [v2 PATCH] mm: pvmw: check possible huge PMD map by transhuge_vma_suitable() To: Muchun Song Cc: Matthew Wilcox , Andrew Morton , Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HVmMMT3X; spf=pass (imf11.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E200A400D8 X-Stat-Signature: 6mi8pkrnd7hfa5o19gpq8z5icw1wxcf6 X-HE-Tag: 1652899521-784966 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 Tue, May 17, 2022 at 10:31 PM Muchun Song wrote: > > On Fri, May 13, 2022 at 12:17:05PM -0700, Yang Shi wrote: > > IIUC PVMW checks if the vma is possibly huge PMD mapped by > > transparent_hugepage_active() and "pvmw->nr_pages >= HPAGE_PMD_NR". > > > > Actually pvmw->nr_pages is returned by compound_nr() or > > folio_nr_pages(), so the page should be THP as long as "pvmw->nr_pages > > >= HPAGE_PMD_NR". And it is guaranteed THP is allocated for valid VMA > > in the first place. But it may be not PMD mapped if the VMA is file > > VMA and it is not properly aligned. The transhuge_vma_suitable() > > is used to do such check, so replace transparent_hugepage_active() to > > it, which is too heavy and overkilling. > > > > Cc: Matthew Wilcox (Oracle) > > Cc: Muchun Song > > Signed-off-by: Yang Shi > > --- > > v2: * Fixed build error for !CONFIG_TRANSPARENT_HUGEPAGE > > * Removed fixes tag per Willy > > > > include/linux/huge_mm.h | 8 ++++++-- > > mm/page_vma_mapped.c | 2 +- > > 2 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > > index fbf36bb1be22..c2826b1f4069 100644 > > --- a/include/linux/huge_mm.h > > +++ b/include/linux/huge_mm.h > > @@ -117,8 +117,10 @@ extern struct kobj_attribute shmem_enabled_attr; > > extern unsigned long transparent_hugepage_flags; > > > > static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, > > - unsigned long haddr) > > + unsigned long addr) > > { > > + unsigned long haddr; > > + > > /* Don't have to check pgoff for anonymous vma */ > > if (!vma_is_anonymous(vma)) { > > if (!IS_ALIGNED((vma->vm_start >> PAGE_SHIFT) - vma->vm_pgoff, > > @@ -126,6 +128,8 @@ static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, > > return false; > > } > > > > + haddr = addr & HPAGE_PMD_MASK; > > + > > if (haddr < vma->vm_start || haddr + HPAGE_PMD_SIZE > vma->vm_end) > > return false; > > return true; > > @@ -328,7 +332,7 @@ static inline bool transparent_hugepage_active(struct vm_area_struct *vma) > > } > > > > static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, > > - unsigned long haddr) > > + unsigned long addr) > > { > > return false; > > } > > diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c > > index c10f839fc410..e971a467fcdf 100644 > > --- a/mm/page_vma_mapped.c > > +++ b/mm/page_vma_mapped.c > > @@ -243,7 +243,7 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw) > > * cleared *pmd but not decremented compound_mapcount(). > > */ > > if ((pvmw->flags & PVMW_SYNC) && > > - transparent_hugepage_active(vma) && > > + transhuge_vma_suitable(vma, pvmw->address) && > > How about the following diff? Then we do not need to change > transhuge_vma_suitable(). All the users of transhuge_vma_suitable() > are already do the alignment by themselves. Thanks for the suggestion. But TBH I don't think this is a better way. I did think about this before proposing v2, but I don't prefer to pollute the code with IS_ENABLED(CONFIG_xxx) since the definition of transhuge_vma_suitable() is already protected by #ifdef. Rounding the address in transhuge_vma_suitable() seems neater and more readable to me IMHO. Some callers of transhuge_vma_suitable() do round the address before calling it, but the rounded address is used by other codes in the callers too. > > Thanks. > > diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c > index c10f839fc410..0aed5ca60c67 100644 > --- a/mm/page_vma_mapped.c > +++ b/mm/page_vma_mapped.c > @@ -243,7 +243,8 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw) > * cleared *pmd but not decremented compound_mapcount(). > */ > if ((pvmw->flags & PVMW_SYNC) && > - transparent_hugepage_active(vma) && > + IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > + transhuge_vma_suitable(vma, pvmw->address & HPAGE_PMD_MASK) && > (pvmw->nr_pages >= HPAGE_PMD_NR)) { > spinlock_t *ptl = pmd_lock(mm, pvmw->pmd); > > > (pvmw->nr_pages >= HPAGE_PMD_NR)) { > > spinlock_t *ptl = pmd_lock(mm, pvmw->pmd); > > > > -- > > 2.26.3 > > > >