On Wed, May 22, 2024 at 03:56:41PM -0700, Andrew Morton wrote: > On Mon, 20 May 2024 11:17:22 +0900 Byungchul Park <byungchul@xxxxxx> wrote: > > > While I'm working with a tiered memory system e.g. CXL memory, I have > > been facing migration overhead esp. tlb shootdown on promotion or > > demotion between different tiers. Yeah.. most tlb shootdowns on > > migration through hinting fault can be avoided thanks to Huang Ying's > > work, commit 4d4b6d66db ("mm,unmap: avoid flushing tlb in batch if PTE > > is inaccessible"). See the following link for more information: > > > > https://lore.kernel.org/lkml/20231115025755.GA29979@xxxxxxxxxxxxxxxxxxx/ > > > > However, it's only for migration through hinting fault. I thought it'd > > be much better if we have a general mechanism to reduce all the tlb > > numbers that we can apply to any unmap code, that we normally believe > > tlb flush should be followed. > > > > I'm suggesting a new mechanism, LUF(Lazy Unmap Flush), defers tlb flush > > until folios that have been unmapped and freed, eventually get allocated > > again. It's safe for folios that had been mapped read-only and were > > unmapped, since the contents of the folios don't change while staying in > > pcp or buddy so we can still read the data through the stale tlb entries. > > Version 10 and no reviewed-by's or acked-by's. Reviewing the review > history isn't helped by the change in the naming of the patch series. > > Seems that you're measuring a ~5% overall speedup in a realistic > workload? That's nice. > > I'll defer this for a week or so to see what reviewers have to say. If > "nothing", please poke me and I guess I'll merge it up to see what I will poke you and will be ready for that ;) Byungchul > happens ;)