From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (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 1F60E3D646D for ; Tue, 24 Mar 2026 12:42:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774356131; cv=none; b=KpR7mzMdAucc3cFeKPiplu9rmMOlqJd00BByrCP5SldYO1/M/1q6VDQyxv/JMQwSohHNMvM85t8nj1YMmohlUqWt/sceEg1ut1fDvnWZEN5AcsnLuvWXNkvme+w9+bmH/7SNz41A7xzH0JKzsGwY2DDIbAClAJtCf3gUIdh46SE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774356131; c=relaxed/simple; bh=OeKcsQ7A+MA2KhMLRM+QctAUwAK+Lrea9T6GU/ALGyM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cOl67ofNcJSfLSR+/FSQ5Z5jABLGtRqP8MhyeBPFlYOwpf8y6Y4Odi2YIm4o7bQ2p7xBoEVIj2iwwNnNO5iPCpAGJj7qq9wWN9gjca+XnCn6H9e4+jnlj7ro8uY/Dwm59+dk2CKip4lW6VZpC1+kTrESe73syfheGRURi7ptnkY= 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=Ri4tlIP0; arc=none smtp.client-ip=115.124.30.118 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="Ri4tlIP0" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774356125; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=3241e3s+MiyU5BLwErJgFwVhtp2oe3MRGyxbrwZaWPo=; b=Ri4tlIP0Meanxv6Kypzu9QN3HNaEHmDXATeDKmpWDJIpKU2znEYw+SDySwVarm06cYpamfV78fTPWCYJJXJU1RJmqN4U7AXP64oEncHVOgpBIPdLgSclvJNiq7l4+M++uxPhOfdqNQZx4rnz8mBG0PxMCcGmKn/TSptCHk/fPRI= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0X.eWkM2_1774356123; Received: from 30.42.98.36(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X.eWkM2_1774356123 cluster:ay36) by smtp.aliyun-inc.com; Tue, 24 Mar 2026 20:42:04 +0800 Message-ID: <551b3c0f-5f49-4c00-ba79-7726e5c5e9de@linux.alibaba.com> Date: Tue, 24 Mar 2026 20:42:03 +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 10/13] mm/huge_memory: separate out the folio part of zap_huge_pmd() To: "Lorenzo Stoakes (Oracle)" Cc: Andrew Morton , David Hildenbrand , Zi Yan , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kiryl Shutsemau , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <6c4db67952f5529da4db102a6149b9050b5dda4e.1774029655.git.ljs@kernel.org> <2f8decdb-4ff7-4482-b50d-6718f25df8f9@lucifer.local> From: Baolin Wang In-Reply-To: <2f8decdb-4ff7-4482-b50d-6718f25df8f9@lucifer.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/23/26 6:42 PM, Lorenzo Stoakes (Oracle) wrote: > On Sat, Mar 21, 2026 at 01:59:34PM +0800, Baolin Wang wrote: >> >> >> On 3/21/26 2:07 AM, Lorenzo Stoakes (Oracle) wrote: >>> Place the part of the logic that manipulates counters and possibly updates >>> the accessed bit of the folio into its own function to make zap_huge_pmd() >>> more readable. >>> >>> Also rename flush_needed to is_present as we only require a flush for >>> present entries. >>> >>> Additionally add comments as to why we're doing what we're doing with >>> respect to softleaf entries. >>> >>> This also lays the ground for further refactoring. >>> >>> Signed-off-by: Lorenzo Stoakes (Oracle) >>> --- >>> mm/huge_memory.c | 61 +++++++++++++++++++++++++++--------------------- >>> 1 file changed, 35 insertions(+), 26 deletions(-) >>> >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>> index 673d0c4734ad..9ddf38d68406 100644 >>> --- a/mm/huge_memory.c >>> +++ b/mm/huge_memory.c >>> @@ -2325,6 +2325,37 @@ static inline void zap_deposited_table(struct mm_struct *mm, pmd_t *pmd) >>> mm_dec_nr_ptes(mm); >>> } >>> +static void zap_huge_pmd_folio(struct mm_struct *mm, struct vm_area_struct *vma, >>> + pmd_t pmdval, struct folio *folio, bool is_present, >>> + bool *has_deposit) >>> +{ >>> + const bool is_device_private = folio_is_device_private(folio); >>> + >>> + /* Present and device private folios are rmappable. */ >>> + if (is_present || is_device_private) >>> + folio_remove_rmap_pmd(folio, &folio->page, vma); >>> + >>> + if (folio_test_anon(folio)) { >>> + *has_deposit = true; >>> + add_mm_counter(mm, MM_ANONPAGES, -HPAGE_PMD_NR); >>> + } else { >>> + add_mm_counter(mm, mm_counter_file(folio), >>> + -HPAGE_PMD_NR); >>> + >>> + /* >>> + * Use flush_needed to indicate whether the PMD entry >>> + * is present, instead of checking pmd_present() again. >>> + */ >>> + if (is_present && pmd_young(pmdval) && >>> + likely(vma_has_recency(vma))) >>> + folio_mark_accessed(folio); >> >> Nit: these comments were added by me to explain why 'flush_needed' was >> used:). Since it has been renamed to the more readable 'is_present', these >> comments are now redundant and can be removed. > > Ack, I think it's _probably_ ok to leave that as a later commit removes it > anyway, if that works for you? Ah, I saw you removed them in the following patch. Looks fine to me. Thanks.