From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7CB119CC28 for ; Wed, 18 Mar 2026 01:37:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773797845; cv=none; b=LWU8Z0a6CdlpLUh1NY2TNvF/cm06YXerOvp9dWZRL8/nSvy/JI+S8332TbKpK7yM8tWblpHBxhTK7K/wbkLxuC+Im85dhNoLI+0STFN657YxVbAHgjBn0uEYOMcRR6ZwsGyp92FJ2b5OA1IbTAVu7jo0F5+bd3mPOzdGNIqicic= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773797845; c=relaxed/simple; bh=NdaWQCAuPf2uL+D2HrqIAy4ub2dBi/HSi8/Wm6dcK1A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=psslPwUnKg4uPMdwnQ8fg51ttknDT20u9HOYdO26WHo003YZ8RDzef01YOJxLTML3zW1CBFfGQayULBdl3kC5LY8biwtyzJWeZ5GViruDE7TNzqPBdM4BZHnqaSFk1kfM2W5ZmQcTXNVGcwlCAyh/AxdiFFw9I0AtiJ4bmuBV5w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=NjtDm5Ti; arc=none smtp.client-ip=115.124.30.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="NjtDm5Ti" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1773797835; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=3xoH794872OOyFq01xqhggvd+hqwGGLWmSAPwLLP/Fw=; b=NjtDm5TiJtE07eVJGZWRHJUIQ/dvDon4obdRsxw0sPVyY6R8o/YzKffSjtwV+tmFHrBpqutkBYzRs7N2gFgynH/j8DE4WIXxxc5qaboPhe9RFxsLxNi7/+4jCvKKuOt0ctMRxHlasBBmPnwpen2RqxRE5VeFv9VBnq32U507jGs= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R961e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0X.CcSSy_1773797832; Received: from 30.74.144.118(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X.CcSSy_1773797832 cluster:ay36) by smtp.aliyun-inc.com; Wed, 18 Mar 2026 09:37:14 +0800 Message-ID: <6bdc4b03-9631-4717-a3fa-2785a7930aba@linux.alibaba.com> Date: Wed, 18 Mar 2026 09:37:12 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/5] mm: rmap: support batched checks of the references for large folios To: Barry Song <21cnbao@gmail.com> Cc: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, catalin.marinas@arm.com, will@kernel.org, lorenzo.stoakes@oracle.com, ryan.roberts@arm.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, riel@surriel.com, harry.yoo@oracle.com, jannh@google.com, willy@infradead.org, dev.jain@arm.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <12132694536834262062d1fb304f8f8a064b6750.1770645603.git.baolin.wang@linux.alibaba.com> <43831628-a00f-4292-9797-cb96a029bb00@kernel.org> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/17/26 3:30 PM, Barry Song wrote: > On Mon, Mar 16, 2026 at 2:25 PM Baolin Wang > wrote: >> >> >> >> On 3/10/26 4:17 PM, David Hildenbrand (Arm) wrote: >>> On 3/10/26 02:37, Baolin Wang wrote: >>>> >>>> >>>> On 3/7/26 4:02 PM, Barry Song wrote: >>>>> On Sat, Mar 7, 2026 at 10:22 AM Baolin Wang >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> Yes. In addition, this will involve many architectures’ implementations >>>>>> and their differing TLB flush mechanisms, so it’s difficult to make a >>>>>> reasonable per-architecture measurement. If any architecture has a more >>>>>> efficient flush method, I’d prefer to implement an architecture‑specific >>>>>> clear_flush_young_ptes(). >>>>> >>>>> Right! Since TLBI is usually quite expensive, I wonder if a generic >>>>> implementation for architectures lacking clear_flush_young_ptes() >>>>> might benefit from something like the below (just a very rough idea): >>>>> >>>>> int clear_flush_young_ptes(struct vm_area_struct *vma, >>>>> unsigned long addr, pte_t *ptep, unsigned int nr) >>>>> { >>>>> unsigned long curr_addr = addr; >>>>> int young = 0; >>>>> >>>>> while (nr--) { >>>>> young |= ptep_test_and_clear_young(vma, curr_addr, >>>>> ptep); >>>>> ptep++; >>>>> curr_addr += PAGE_SIZE; >>>>> } >>>>> >>>>> if (young) >>>>> flush_tlb_range(vma, addr, curr_addr); >>>>> return young; >>>>> } >>>> >>>> I understand your point. I’m concerned that I can’t test this patch on >>>> every architecture to validate the benefits. Anyway, let me try this on >>>> my X86 machine first. >>> >>> In any case, please make that a follow-up patch :) >> >> Sure. However, after investigating RISC‑V and x86, I found that >> ptep_clear_flush_young() does not flush the TLB on these architectures: >> >> int ptep_clear_flush_young(struct vm_area_struct *vma, >> unsigned long address, pte_t *ptep) >> { >> /* >> * On x86 CPUs, clearing the accessed bit without a TLB flush >> * doesn't cause data corruption. [ It could cause incorrect >> * page aging and the (mistaken) reclaim of hot pages, but the >> * chance of that should be relatively low. ] >> * >> * So as a performance optimization don't flush the TLB when >> * clearing the accessed bit, it will eventually be flushed by >> * a context switch or a VM operation anyway. [ In the rare >> * event of it not getting flushed for a long time the delay >> * shouldn't really matter because there's no real memory >> * pressure for swapout to react to. ] >> */ >> return ptep_test_and_clear_young(vma, address, ptep); >> } >> >> I don't have access to other architectures, so I think we can postpone >> this optimization unless someone is interested in optimizing the TLB flush. > > The comment is interesting. I think it likely applies to most > architectures, including ARM64. The main reason ARM64 doesn’t use > this approach is probably that it can issue tlbi_nosync and then > rely on a final dsb to ensure all invalidations are completed— > and tlbi_nosync itself is relatively cheap. Actually, we both tried this a few years ago, but neither succeeded :). My patch: https://lkml.org/lkml/2023/10/24/533 Your patch: https://lore.kernel.org/lkml/20220617070555.344368-1-21cnbao@gmail.com/ Now I’m more inclined toward your approach, to align with MGLRU. It’s time to restart the discussion on this patch? :)