[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240513014428.GB38851@system.software.com>
Date: Mon, 13 May 2024 10:44:29 +0900
From: Byungchul Park <byungchul@...com>
To: "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 Sat, May 11, 2024 at 03:15:01PM +0800, Huang, Ying wrote:
> Byungchul Park <byungchul@...com> writes:
>
> > Hi everyone,
> >
> > 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@system.software.com/
>
> And, I still have interest of the performance impact of commit
> 7e12beb8ca2a ("migrate_pages: batch flushing TLB"). In the email above,
> you said that the performance of v6.5-rc5 + 7e12beb8ca2a reverted has
> better performance than v6.5-rc5. Can you provide more details? For
> example, the number of TLB flushing IPI for two kernels?
Okay. I will test and share the result with what you asked me now once
I get available for the test.
Byungchul
> I should have followed up the above email. Sorry about that. Anyway,
> we should try to fix issue of that commit too.
>
> --
> Best Regards,
> Huang, Ying
>
> [snip]
Powered by blists - more mailing lists