Received-SPF: pass (google.com: domain of linux-kernel+bounces-196179-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 31 May 2024 11:06:54 +0900
From: Byungchul Park <byungchul@sk.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: "Huang, Ying" <ying.huang@intel.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, willy@infradead.org,
	david@redhat.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 v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers
 over 90%
Message-ID: <20240531020654.GA62639@system.software.com>
References: <8734q46jc8.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <44e4f2fd-e76e-445d-b618-17a6ec692812@intel.com>
 <20240529050046.GB20307@system.software.com>
 <961f9533-1e0c-416c-b6b0-d46b97127de2@intel.com>
 <20240530005026.GA47476@system.software.com>
 <87a5k814tq.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <20240530071847.GA15344@system.software.com>
 <871q5j1zdf.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <20240530084120.GA12940@system.software.com>
 <2a0f8cc9-a061-45cd-81df-b65d4b454b77@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2a0f8cc9-a061-45cd-81df-b65d4b454b77@intel.com>
User-Agent: Mutt/1.9.4 (2018-02-28)

On Thu, May 30, 2024 at 06:50:48AM -0700, Dave Hansen wrote:
> On 5/30/24 01:41, Byungchul Park wrote:
> > LUF should not optimize tlb flushes for mappings that users explicitly
> > change e.g. through mmap() and munmap().
> 
> We are thoroughly going around in circles at this point.
> 
> I'm not quite sure what to do.  Ying and I see a problem that we've
> tried to explain a couple of times.  We've tried to show the connection
> between a LUF-elided TLB flush and how that could affect a later
> munmap() or mmap(MAP_FIXED).
> 
> But these responses seem to keep going back to the fact that LUF doesn't

I just wanted to understand exactly what Ying meant.  My answer might be
done in a wrong way if I wrongly got him.

> directly affect munmap(), which is true, but quite irrelevant to the
> problem being described.
> 
> So we're at an impasse.
> 
> Byungchul, perhaps you should spin another series and maybe Ying and I

I don't think the current implementation is perfect.  I just wanted to
know what I'm missing now but.. yes.  It would be much better to
communicate with a real bug if existing.

I will respin the next version shortly.

	Byungchul

> have to write up a test case to show the bug that we see.  Or perhaps
> someone else can jump into the thread and bridge the communication gap.