[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a0f8cc9-a061-45cd-81df-b65d4b454b77@intel.com>
Date: Thu, 30 May 2024 06:50:48 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Byungchul Park <byungchul@...com>, "Huang, Ying" <ying.huang@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
kernel_team@...ynix.com, akpm@...ux-foundation.org, vernhao@...cent.com,
mgorman@...hsingularity.net, hughd@...gle.com, willy@...radead.org,
david@...hat.com, peterz@...radead.org, luto@...nel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, rjgolo@...il.com
Subject: Re: [PATCH v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over
90%
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
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
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.
Powered by blists - more mailing lists