From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (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 0FEEA3AA1AE for ; Tue, 10 Mar 2026 02:51:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773111080; cv=none; b=oXful65MQOxEhawiQz94T0Fnsg3sQw900nAUOJPsIOfDSxUJDp7C7KjcwBRUWozoix/GbrvOJb7zXYoDpXtpsimsSp2KPSW+My/dsmGsET8qOSZs8RUMJrgC4LWaUtdz/t80Ace2XPGIMNN06zM4yjJiJ8pJ/SD1QpB6agNheBo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773111080; c=relaxed/simple; bh=u0YiIJH+P77IwrjdgeaC5drPjZQQogMSs0mZ+/WAk94=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cLJ7IDt3hDu1bGGVN0V8EP8WD2d6UTJBhe7Bkl2QaCT7sJob1djeF0Y5D9oHa0PVSEdPkchu5MxMXCAlkbhEr4q1CSIrKZBQMAZtoGHNUZo4gPiwCZMsQJncoNzVw7vHaXFB8fz6L87pFgRGw97I9Aymd+ImvN7uuvm5xRGkBu0= 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=ununkg+1; arc=none smtp.client-ip=115.124.30.130 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="ununkg+1" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1773111068; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=aOzjae/W+WCxIMUGhwZr1WeqcdnegQLRX5RKCOr4bFk=; b=ununkg+1fs4GbsCGVVeDYLEWn85oITxMAEYKIj4PT8t/AglXEPR8wv9BMrimcmUh3W00bZuiFnlgOq6qDdOLVxpPswMI0ZnhjCPhYvyZsoWGxUjv5oWrk24BIXJASoHV2GOVOBl1B+xDOmW1cXa9L7NiBy4M2aJ+8o/WaSvUU+w= Received: from 30.74.144.119(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X-eKuga_1773111066 cluster:ay36) by smtp.aliyun-inc.com; Tue, 10 Mar 2026 10:51:07 +0800 Message-ID: <9b324c40-d148-4c1b-bcbb-7bd07c4f6bbb@linux.alibaba.com> Date: Tue, 10 Mar 2026 10:51:06 +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 6/6] arm64: mm: implement the architecture-specific test_and_clear_young_ptes() To: "David Hildenbrand (Arm)" , akpm@linux-foundation.org Cc: 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, baohua@kernel.org, dev.jain@arm.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, hannes@cmpxchg.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <7f891d42a720cc2e57862f3b79e4f774404f313c.1772778858.git.baolin.wang@linux.alibaba.com> <6305e05e-2911-42b0-b6f5-7fdde787b778@kernel.org> <92376758-5bb5-4391-8904-cd0e2f72acf8@kernel.org> From: Baolin Wang In-Reply-To: <92376758-5bb5-4391-8904-cd0e2f72acf8@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/9/26 10:39 PM, David Hildenbrand (Arm) wrote: >>> >>> (b) The first pte is !pte_cont(), but some others in there are? >> >> IMO they can’t be handled in a single batch. Since the folio_pte_batch() >> will group consecutive !cont PTEs into one batch and consecutive cont >> PTEs into another (assume all PTEs belong to a single large folio), >> because their PTE entries have different CONT bits. > Interesting, thanks. I thought that folio_pte_batch() would be able to > batch that. > > But yes, pte_batch_hint() relies on the CONT bit still being set after a > ptep_get(). I wonder whether we should document somewhere that the arm > implementation depends on that. > > This might be something to look into in the future. (make > folio_pte_batch() ignore cont information when comparing and make the > arm implementation be able to deal with that). > > Assume we unmapped the last page of a large folio. Ideally, we'd be able > to process the remaining THP pieces (all ptes) in a single operation. I > guess right now it would be two. Right. Let me investigate this further and see if I can figure out how to optimize this case. Thanks for reviewing.