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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 88C9AC43334 for ; Fri, 10 Jun 2022 03:59:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OKQXDBaivmBENsfh7Q0NpobfJIaSUCgVFH52RsOKUPM=; b=0EN6jsItKBJtkL oONvy+DLY+4XRoPC12MKCL/ZUym1ZKETLJMrQh/apcrhsWvHzKQGULq1aguo4wK9GYgArWeO6dFCI JpZbKCDBvbo4DslYANcA3cHjyDcJB6k1Wb1NAfcR6EspduTMwB2YgQGWf0QN845eY/pockfe3Wzy+ 0DIhnvHnNjcG2qLJv6zU1yGpwFr1836gPcfh1PRIBBlN/b31zKnBRBpXbbheaVMsAblMBmFU9J+h1 8AGRJPPFt7SzDk3yzMf5bdJ9kw1hRroxqY5jpaNtQq6pu9TVs4K2MSMwpd4m0cTjtBl02Gse7h6eC E0AutrLBMmmyi7QMQZ8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nzVmZ-005c3K-A6; Fri, 10 Jun 2022 03:57:59 +0000 Received: from out30-57.freemail.mail.aliyun.com ([115.124.30.57]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nzVmT-005byz-0h for linux-arm-kernel@lists.infradead.org; Fri, 10 Jun 2022 03:57:55 +0000 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0VFxf77o_1654833464; Received: from 30.0.143.52(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VFxf77o_1654833464) by smtp.aliyun-inc.com; Fri, 10 Jun 2022 11:57:45 +0800 Message-ID: <927ab454-f25d-06d2-5861-a57033f28e00@linux.alibaba.com> Date: Fri, 10 Jun 2022 11:57:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH] arm64/hugetlb: Simplify the huge_ptep_set_access_flags() To: Will Deacon Cc: catalin.marinas@arm.com, mike.kravetz@oracle.com, songmuchun@bytedance.com, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20220609154438.GA3444@willie-the-truck> From: Baolin Wang In-Reply-To: <20220609154438.GA3444@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220609_205753_294444_C95275E9 X-CRM114-Status: GOOD ( 19.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 6/9/2022 11:44 PM, Will Deacon wrote: > On Wed, May 25, 2022 at 06:31:09PM +0800, Baolin Wang wrote: >> After commit bc5dfb4fd7bd ("arm64/hugetlb: Implement arm64 specific >> huge_ptep_get()"), the arm64 specific huge_ptep_get() will always >> consider the subpages' dirty and young state for CONT-PTE/PMD hugetlb, >> so there is no need to check them again when setting the access flags >> for CONT-PTE/PMD hugetlb in huge_ptep_set_access_flags(). >> >> Meanwhile this also fixes an issue when users want to make the CONT-PTE/PMD >> hugetlb's pte entry old, which will be failed to make the pte entry old >> since the original code will always consider the subpages' young state >> if the subpages' young state is set. For example, we will make the >> CONT-PTE/PMD hugetlb pte entry old in DAMON to monitoring the accesses, >> but we'll failed to monitoring the actual accesses of the CONT-PTE/PMD >> hugetlb page, due to we can not make its pte old. >> >> Thus remove the code considering the subpages' dirty and young state in >> huge_ptep_set_access_flags() to fix this issue and simplify the function. >> >> Signed-off-by: Baolin Wang >> --- >> arch/arm64/mm/hugetlbpage.c | 10 +--------- >> 1 file changed, 1 insertion(+), 9 deletions(-) >> >> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c >> index e2a5ec9..5c703aa 100644 >> --- a/arch/arm64/mm/hugetlbpage.c >> +++ b/arch/arm64/mm/hugetlbpage.c >> @@ -448,7 +448,6 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma, >> size_t pgsize = 0; >> unsigned long pfn = pte_pfn(pte), dpfn; >> pgprot_t hugeprot; >> - pte_t orig_pte; >> >> if (!pte_cont(pte)) >> return ptep_set_access_flags(vma, addr, ptep, pte, dirty); >> @@ -459,14 +458,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma, >> if (!__cont_access_flags_changed(ptep, pte, ncontig)) >> return 0; >> >> - orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig); >> - >> - /* Make sure we don't lose the dirty or young state */ >> - if (pte_dirty(orig_pte)) >> - pte = pte_mkdirty(pte); >> - >> - if (pte_young(orig_pte)) >> - pte = pte_mkyoung(pte); >> + clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig); > > I don't understand what this clear_flush() call is doing here; notably, it > includes TLB invalidation which we don't have for the non-cont case. OK. I can just call a loop of pte_clear() to clear cont-pte to avoid TLB flush. > > Why isn't huge_ptep_set_access_flags() just a loop around > ptep_set_access_flags() if huge_ptep_get() is taking care of collapsing the > dirty/young state? IIUC, according to the comments "Changing some bits of contiguous entries requires us to follow a Break-Before-Make approach, breaking the whole contiguous set before we can change any entries". So we should clear the cont-ptes firstly, then re-set them. Then a loop of ptep_set_access_flags() is not suitable for the cont-pte case, right? Please correct me if I missed something else. Thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel