Received-SPF: pass (google.com: domain of linux-kernel+bounces-209148-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Tue, 11 Jun 2024 09:55:23 +0900
From: Byungchul Park <byungchul@sk.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Dave Hansen <dave.hansen@intel.com>,
	David Hildenbrand <david@redhat.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,
	ying.huang@intel.com, 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
Message-ID: <20240611005523.GA4384@system.software.com>
References: <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>
 <20240604003448.GA26609@system.software.com>
 <Zmb-ZZHbeNNjcs68@tiehlicka>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zmb-ZZHbeNNjcs68@tiehlicka>
User-Agent: Mutt/1.9.4 (2018-02-28)

On Mon, Jun 10, 2024 at 03:23:49PM +0200, Michal Hocko wrote:
> On Tue 04-06-24 09:34:48, Byungchul Park wrote:
> > On Mon, Jun 03, 2024 at 06:01:05PM +0100, 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.
> > > 
> > > > 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.
> > > 
> > > I'm more concerned with:
> > > 
> > >  - page goes back to buddy
> > >  - page is allocated to slab
> > 
> > At this point, tlb flush needed will be performed in prep_new_page().
> 
> But that does mean that an unaware caller would get an additional
> overhead of the flushing, right? I think it would be just a matter of

pcp for locality is already a better source of side channel attack.  FYI,
tlb flush gets barely performed only if pending tlb flush exists.

> time before somebody can turn that into a side channel attack, not to
> mention unexpected latencies introduced.

Nope.  The pending tlb flush performed in prep_new_page() is the one
that would've done already with the vanilla kernel.  It's not additional
tlb flushes but it's subset of all the skipped ones.

It's worth noting all the existing mm reclaim mechaisms have already
introduced worse unexpected latencies.

	Byungchul

> -- 
> Michal Hocko
> SUSE Labs