linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zhang Peng <zippermonkey@icloud.com>
To: usama.arif@linux.dev
Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org,
	axelrasmussen@google.com, bruzzhang@tencent.com,
	david@kernel.org, devnull+zippermonkey.icloud.com@kernel.org,
	hannes@cmpxchg.org, kasong@tencent.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org,
	mhocko@kernel.org, mhocko@suse.com, rppt@kernel.org,
	shakeel.butt@linux.dev, surenb@google.com, vbabka@kernel.org,
	weixugc@google.com, yuanchu@google.com,
	zhengqi.arch@bytedance.com
Subject: Re: [PATCH 2/2] mm, vmscan: flush TLB for every 31 folios evictions
Date: Mon, 9 Mar 2026 22:56:27 +0800	[thread overview]
Message-ID: <fe90adfa-cdb9-4d64-8161-7a944fe8020a@icloud.com> (raw)
In-Reply-To: <20260309122939.723610-1-usama.arif@linux.dev>

Hi Usama,

Thanks for the review!

You are right that the comment is wrong, page_ref_freeze does not exist in
pageout_batch(). I will fix the comment in v2.

Regarding the data corruption concern: try_to_unmap_flush_dirty() is called
before pageout_one(), so all stale writable TLB entries are invalidated 
before
IO starts. Any writes through stale TLB entries during the unlocked 
window will
have completed and landed in physical memory before the flush, and will be
correctly captured by the subsequent IO.

pageout_batch() relocks each folio and rechecks its state (writeback, lru,
mapped, dma_pinned) before proceeding. If any of these conditions have 
changed
during the unlocked window, the folio is not written out and is put back 
to the
LRU list for a future reclaim attempt. So there should be no data corruption
issue.

I will also add folio_maybe_dma_pinned() check in v2 as suggested by 
Kairui Song.


      parent reply	other threads:[~2026-03-09 14:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09  8:17 [PATCH 0/2] mm: batch TLB flushing for dirty folios in vmscan Zhang Peng via B4 Relay
2026-03-09  8:17 ` [PATCH 1/2] mm/vmscan: refactor shrink_folio_list for readability and maintainability Zhang Peng via B4 Relay
2026-03-09  8:17 ` [PATCH 2/2] mm, vmscan: flush TLB for every 31 folios evictions Zhang Peng via B4 Relay
2026-03-09 12:29   ` Usama Arif
2026-03-09 13:19     ` Kairui Song
2026-03-09 14:56     ` Zhang Peng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fe90adfa-cdb9-4d64-8161-7a944fe8020a@icloud.com \
    --to=zippermonkey@icloud.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=bruzzhang@tencent.com \
    --cc=david@kernel.org \
    --cc=devnull+zippermonkey.icloud.com@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    --cc=zhengqi.arch@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox