Received-SPF: pass (google.com: domain of linux-kernel+bounces-200237-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: "Huang, Ying" <ying.huang@intel.com>
To: David Hildenbrand <david@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,  Dave Hansen
 <dave.hansen@intel.com>,  Byungchul Park <byungchul@sk.com>,  Byungchul
 Park <lkml.byungchul.park@gmail.com>,  linux-kernel@vger.kernel.org,
  linux-mm@kvack.org,  kernel_team@skhynix.com,  akpm@linux-foundation.org,
  vernhao@tencent.com,  mgorman@techsingularity.net,  hughd@google.com,
  peterz@infradead.org,  luto@kernel.org,  tglx@linutronix.de,
  mingo@redhat.com,  bp@alien8.de,  dave.hansen@linux.intel.com,
  rjgolo@gmail.com
Subject: Re: [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering
 tlb flush when folios get unmapped
In-Reply-To: <24daabde-300e-4a28-9a1c-9e406b087195@redhat.com> (David
	Hildenbrand's message of "Mon, 3 Jun 2024 20:00:52 +0200")
References: <20240531092001.30428-1-byungchul@sk.com>
	<20240531092001.30428-10-byungchul@sk.com>
	<fab1dd64-c652-4160-93b4-7b483a8874da@intel.com>
	<CAHyrMpxETdVewTH3MCS4qPyD6Xf1zRUfWZf-8SCdpCFj2Pj_Wg@mail.gmail.com>
	<f17f33e8-1c1f-460f-8c5a-713476f524a3@intel.com>
	<26dc4594-430b-483c-a26c-7e68bade74b0@redhat.com>
	<20240603093505.GA12549@system.software.com>
	<d650c29b-129f-4fac-9a9d-ea1fbdae2c3a@intel.com>
	<35866f91-7d96-462a-aa0a-ac8a6b8cbcf8@redhat.com>
	<196481bb-b86d-4959-b69b-21fda4daae77@intel.com>
	<Zl320dWODSYw-PgV@casper.infradead.org>
	<24daabde-300e-4a28-9a1c-9e406b087195@redhat.com>
Date: Tue, 04 Jun 2024 16:16:49 +0800
Message-ID: <877cf5ceby.fsf@yhuang6-desk2.ccr.corp.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii

David Hildenbrand <david@redhat.com> writes:

> On 03.06.24 19:01, Matthew Wilcox wrote:
>> On Mon, Jun 03, 2024 at 09:37:46AM -0700, Dave Hansen wrote:
>>> Yeah, we'd need some equivalent of a PTE marker, but for the page cache.
>>>   Presumably some xa_value() that means a reader has to go do a
>>> luf_flush() before going any farther.
>> I can allocate one for that.  We've got something like 1000
>> currently
>> unused values which can't be mistaken for anything else.
>
> I'm curious when to set that, though.
>
> While migrating/reclaiming, when unmapping the folio from the page
> tables, the folio is still valid in the page cache. So at the point in
> time of unmapping from one process, we cannot simply replace the folio
> in the page cache by some other value -- I think.
>
> Maybe it's all easier than I think.

IIUC, we need to held folio lock before replacing the folio in the page
cache.  In page_cache_delete(), folio_test_locked() is checked.  And, we
will lock the folio before writing to it via write syscall.  So, it's
safe to defer TLB flushing until we unlock the folio.

--
Best Regards,
Huang, Ying