linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: David Hildenbrand <david@redhat.com>, Byungchul Park <byungchul@sk.com>
Cc: Byungchul Park <lkml.byungchul.park@gmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	kernel_team@skhynix.com, akpm@linux-foundation.org,
	ying.huang@intel.com, vernhao@tencent.com,
	mgorman@techsingularity.net, hughd@google.com,
	willy@infradead.org, 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
Date: Mon, 3 Jun 2024 09:37:46 -0700	[thread overview]
Message-ID: <196481bb-b86d-4959-b69b-21fda4daae77@intel.com> (raw)
In-Reply-To: <35866f91-7d96-462a-aa0a-ac8a6b8cbcf8@redhat.com>

On 6/3/24 09:05, David Hildenbrand wrote:
...
>>    2. A LUF'd page's position in the page cache can't be replaced until
>>       after a luf_flush()
> 
> That's the most tricky bit. I think these are the VFS concerns like
> 
> 1) Page migration/reclaim ends up freeing the old page. TLB not flushed.
> 2) write() to the new page / write from other process to the new page
> 3) CPU reads stale content from old page
> 
> PTE markers can't handle that.

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.

That would actually have a chance at fixing two issues:  One where a new
page cache insertion is attempted.  The other where someone goes to look
in the page cache and takes some action _because_ it is empty (I think
NFS is doing some of this for file locks).

LUF is also pretty fundamentally built on the idea that files can't
change without LUF being aware.  That model seems to work decently for
normal old filesystems on normal old local block devices.  I'm worried
about NFS, and I don't know how seriously folks take FUSE, but it
obviously can't work well for FUSE.


  reply	other threads:[~2024-06-03 16:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31  9:19 [PATCH v11 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over 90% Byungchul Park
2024-05-31  9:19 ` [PATCH v11 01/12] x86/tlb: add APIs manipulating tlb batch's arch data Byungchul Park
2024-05-31  9:19 ` [PATCH v11 02/12] arm64: tlbflush: " Byungchul Park
2024-05-31  9:19 ` [PATCH v11 03/12] riscv, tlb: " Byungchul Park
2024-05-31  9:19 ` [PATCH v11 04/12] x86/tlb, riscv/tlb, mm/rmap: separate arch_tlbbatch_clear() out of arch_tlbbatch_flush() Byungchul Park
2024-05-31  9:19 ` [PATCH v11 05/12] mm: buddy: make room for a new variable, ugen, in struct page Byungchul Park
2024-05-31  9:19 ` [PATCH v11 06/12] mm: add folio_put_ugen() to deliver unmap generation number to pcp or buddy Byungchul Park
2024-05-31  9:19 ` [PATCH v11 07/12] mm: add a parameter, unmap generation number, to free_unref_folios() Byungchul Park
2024-05-31  9:19 ` [PATCH v11 08/12] mm/rmap: recognize read-only tlb entries during batched tlb flush Byungchul Park
2024-05-31  9:19 ` [PATCH v11 09/12] mm: implement LUF(Lazy Unmap Flush) defering tlb flush when folios get unmapped Byungchul Park
2024-05-31 16:12   ` Dave Hansen
2024-05-31 18:04     ` Byungchul Park
2024-05-31 21:46       ` Dave Hansen
2024-05-31 22:09         ` Matthew Wilcox
2024-06-01  2:20         ` Byungchul Park
2024-06-01  7:22         ` David Hildenbrand
2024-06-03  9:35           ` Byungchul Park
2024-06-03 13:23             ` Dave Hansen
2024-06-03 16:05               ` David Hildenbrand
2024-06-03 16:37                 ` Dave Hansen [this message]
2024-06-03 17:01                   ` Matthew Wilcox
2024-06-03 18:00                     ` David Hildenbrand
2024-06-04  8:16                       ` Huang, Ying
2024-06-04  0:34                     ` Byungchul Park
2024-06-10 13:23                       ` Michal Hocko
2024-06-11  0:55                         ` Byungchul Park
2024-06-11 11:55                           ` Michal Hocko
2024-06-14  2:45                             ` Byungchul Park
2024-06-04  1:53               ` Byungchul Park
2024-06-04  4:43                 ` Byungchul Park
2024-06-06  8:33                   ` David Hildenbrand
2024-06-14  1:57                 ` Byungchul Park
2024-06-11  9:12               ` Byungchul Park
2024-05-31  9:19 ` [PATCH v11 10/12] mm: separate move/undo parts from migrate_pages_batch() Byungchul Park
2024-05-31  9:20 ` [PATCH v11 11/12] mm, migrate: apply luf mechanism to unmapping during migration Byungchul Park
2024-05-31  9:20 ` [PATCH v11 12/12] mm, vmscan: apply luf mechanism to unmapping during folio reclaim Byungchul Park

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=196481bb-b86d-4959-b69b-21fda4daae77@intel.com \
    --to=dave.hansen@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=byungchul@sk.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kernel_team@skhynix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkml.byungchul.park@gmail.com \
    --cc=luto@kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rjgolo@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=vernhao@tencent.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.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