From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (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 3B4872253EE for ; Sat, 20 Dec 2025 04:29:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766204963; cv=none; b=FoOoYfcLyilv/F32PiV/QiQyOvZGIJDcIstB8tEl0nHnlPlk9NBv37gMUP73BqukUz6t2yo43gEpU0YMbKuyLpVcKN7+p+b1tokteSijWkCzqrcmwyMQBZdcJ1X+WhksqDnJIUmjMAT/349GTa0kyI14TJ0/zPzzgq76q1VPWJY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766204963; c=relaxed/simple; bh=V7fS+3wNDK0gPy8aODJyzxlacWme++I8zbkqs/dvpHc=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=uMi3zqPV8QxumqEa18GlS25rJ4YCbaLLcPLFQQ6iyx7YWM8YzJS9qa1rCqV//vH8iWsoWJQTLV+EhHxvocYwsM1Ws6ZLHivGYtnsTbHUZcNsHghX1DPXY69GIrm0ohR0DlTHqTOcTxR6yo6EczGvmL1dFhtBaSz1JmoKfTeooEo= 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=woWtFC8D; arc=none smtp.client-ip=115.124.30.119 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="woWtFC8D" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1766204955; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=cO8WtEaXesAo47SuaG+o4/YJs4sol1oYaZp1SwxhQ0k=; b=woWtFC8DFaElUqBMdx6sb+qbrhswM5mFwAtjHxVfPA4Jti/ao60IsV+XS+Pd/xQ9ee/3WxdzeqqVNR/Rfa4V93Gx7OlIukWy+4gJf9ApQBzNJL6hRKuBpcgbj3+mpLMM616+CexNi+wCH8lEcdXcJMTJ90pFUnjI5fvbW5/zgvY= Received: from 30.170.69.111(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WvF13NW_1766204952 cluster:ay36) by smtp.aliyun-inc.com; Sat, 20 Dec 2025 12:29:13 +0800 Message-ID: <17b923c4-48cc-45f0-93fe-84a13568c1bf@linux.alibaba.com> Date: Sat, 20 Dec 2025 12:29:11 +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 v3 1/5] mm: rmap: support batched checks of the references for large folios To: Matthew Wilcox , "Liam R. Howlett" , akpm@linux-foundation.org, david@kernel.org, catalin.marinas@arm.com, will@kernel.org, lorenzo.stoakes@oracle.com, ryan.roberts@arm.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, riel@surriel.com, harry.yoo@oracle.com, jannh@google.com, baohua@kernel.org, dev.jain@arm.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <24b9d33acad627997febe9b61d398fc53739a333.1766121341.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025/12/20 00:09, Matthew Wilcox wrote: > On Fri, Dec 19, 2025 at 10:47:52AM -0500, Liam R. Howlett wrote: >>> -#define ptep_clear_flush_young_notify(__vma, __address, __ptep) \ >>> +#define ptep_clear_flush_young_notify(__vma, __address, __ptep, __nr) \ >>> ({ \ >>> int __young; \ >>> struct vm_area_struct *___vma = __vma; \ >>> unsigned long ___address = __address; \ >>> - __young = ptep_clear_flush_young(___vma, ___address, __ptep); \ >>> + unsigned int ___nr = __nr; \ >>> + __young = clear_flush_young_ptes(___vma, ___address, __ptep, ___nr); \ >>> __young |= mmu_notifier_clear_flush_young(___vma->vm_mm, \ >>> ___address, \ >>> ___address + \ >>> - PAGE_SIZE); \ >>> + nr * PAGE_SIZE); \ >> >> Did you mean nr * PAGE_SIZE here? I think it should be __nr or ___nr? >> I think this nr variable works because it exists where this macro is >> expanded? > > Yes, this should clearly be ___nr. Ah, yes, my mistake. Thanks for pointing it out. Will fix. > >> I am also not sure why you have ___nr at all? > > It's a macro cleanliness thing. Imagine that we have a caller: > > a = ptep_clear_flush_young_notify(vma, addr, ptep, nr++); > > If you have two references to the __nr macro argument, then you end up > incrementing nr twice. Assigning __nr to ___nr and then referring to > ___nr within the macro prevents this. Yes. > That said, I'm not sure why ptep_clear_flush_young_notify() needs > to be a macro instead of a static inline? Lorenzo also mentioned this. I'll clean up these macros in a follow-up after this patchset. Thanks.