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 EBEAAC433EF for ; Wed, 18 May 2022 00:05:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 659A86B0072; Tue, 17 May 2022 20:05:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6081F6B0073; Tue, 17 May 2022 20:05:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A94C6B0074; Tue, 17 May 2022 20:05:07 -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 368676B0072 for ; Tue, 17 May 2022 20:05:07 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 048F120502 for ; Wed, 18 May 2022 00:05:06 +0000 (UTC) X-FDA: 79476918654.31.DA8EB7A Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf25.hostedemail.com (Postfix) with ESMTP id 0D05DA009E for ; Wed, 18 May 2022 00:04:42 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 576AAB80B25; Wed, 18 May 2022 00:05:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9DD7C385B8; Wed, 18 May 2022 00:05:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1652832303; bh=002uA/OhCvgSuCBXwvu+tXYkgZTTOLcnGkvUEQBf7LI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AutC+nYSX1aPAKJulnJ4OmrJOn8VnWdcmA+sOROdyQgX/TybUILLrdH3kxIaGCHX5 Ak+dBVPuBTzcWumqSUQgIsKtQt+6p2NaOD2ar62iQN9xTsjSdtgjyYar6UR9z1ps8T PTr1NHeSSdrRzbHwWFKHRW6bvGb0b2xzsjS/jWeA= Date: Tue, 17 May 2022 17:05:02 -0700 From: Andrew Morton To: Yang Shi Cc: willy@infradead.org, songmuchun@bytedance.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [v2 PATCH] mm: pvmw: check possible huge PMD map by transhuge_vma_suitable() Message-Id: <20220517170502.cf4433f5cd1e69f27305cf19@linux-foundation.org> In-Reply-To: <20220513191705.457775-1-shy828301@gmail.com> References: <20220513191705.457775-1-shy828301@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0D05DA009E X-Stat-Signature: zop7n1i5594yyh5zwcb59pgehxa8wcx9 X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=AutC+nYS; spf=pass (imf25.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam09 X-HE-Tag: 1652832282-894337 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, 13 May 2022 12:17:05 -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. I messed with the changelog a bit. The function is called page_vma_mapped_walk(), so let's call it that. This patch has been in the trees since May 12, which isn't terribly long. Does anyone feel up to a reviewed-by? Thanks. From: Yang Shi Subject: mm/page_vma_mapped.c: check possible huge PMD map with transhuge_vma_suitable() Date: Fri, 13 May 2022 12:17:05 -0700 IIUC page_vma_mapped_walk() checks if the vma is possibly huge PMD mapped with 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. Link: https://lkml.kernel.org/r/20220513191705.457775-1-shy828301@gmail.com Signed-off-by: Yang Shi Cc: Matthew Wilcox (Oracle) Cc: Muchun Song Signed-off-by: Andrew Morton --- include/linux/huge_mm.h | 8 ++++++-- mm/page_vma_mapped.c | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) --- a/include/linux/huge_mm.h~mm-pvmw-check-possible-huge-pmd-map-by-transhuge_vma_suitable +++ a/include/linux/huge_mm.h @@ -117,8 +117,10 @@ extern struct kobj_attribute shmem_enabl 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_suitabl return false; } + haddr = addr & HPAGE_PMD_MASK; + if (haddr < vma->vm_start || haddr + HPAGE_PMD_SIZE > vma->vm_end) return false; return true; @@ -342,7 +346,7 @@ static inline bool transparent_hugepage_ } static inline bool transhuge_vma_suitable(struct vm_area_struct *vma, - unsigned long haddr) + unsigned long addr) { return false; } --- a/mm/page_vma_mapped.c~mm-pvmw-check-possible-huge-pmd-map-by-transhuge_vma_suitable +++ a/mm/page_vma_mapped.c @@ -243,7 +243,7 @@ restart: * cleared *pmd but not decremented compound_mapcount(). */ if ((pvmw->flags & PVMW_SYNC) && - transparent_hugepage_active(vma) && + transhuge_vma_suitable(vma, pvmw->address) && (pvmw->nr_pages >= HPAGE_PMD_NR)) { spinlock_t *ptl = pmd_lock(mm, pvmw->pmd); _