linux-kernel - Re: [v4 0/3] Reduce TLB flushes under some specific conditions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231115064311.GA41022@system.software.com>
Date:   Wed, 15 Nov 2023 15:43:11 +0900
From:   Byungchul Park <byungchul@...com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        kernel_team@...ynix.com, akpm@...ux-foundation.org,
        ying.huang@...el.com, namit@...are.com, xhao@...ux.alibaba.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
Subject: Re: [v4 0/3] Reduce TLB flushes under some specific conditions

On Thu, Nov 09, 2023 at 06:26:08AM -0800, Dave Hansen wrote:
> On 11/8/23 20:59, Byungchul Park wrote:
> > Can you believe it? I saw the number of TLB full flush reduced about
> > 80% and iTLB miss reduced about 50%, and the time wise performance
> > always shows at least 1% stable improvement with the workload I tested
> > with, XSBench. However, I believe that it would help more with other
> > ones or any real ones. It'd be appreciated to let me know if I'm missing
> > something.
> 
> I see that you've moved a substantial amount of code out of arch/x86.
> That's great.
> 
> But there doesn't appear to be any improvement in the justification or
> performance data.  The page flag is also here, which is horribly frowned
> upon.  It's an absolute no-go with this level of justification.
> 
> I'd really suggest not sending any more of these out until those issues
> are rectified.  I know I definitely won't be reviewing them in this state.

As I expected, I got a fair better result when I tested migrc with a
system with a slower DRAM to make TLB miss overhead stand out.

   1. XSBench execution time was reduced about 7%.
   2. iTLB flush # was reduced stably about 90% while running XSBench.
   3. iTLB miss # was reduced stably about 50% while running XSBench.

https://lore.kernel.org/lkml/20231115025755.GA29979@system.software.com/

Of course, I can reimplement migrc to replace PG_migrc with another
thing like hash table but, IMHO, it's worth having the page flag if it
gives such a good performance. Lemme know if not so that I'll change the
way to implement.

I'd like to note that no doubt migrc significantly reduces TLB miss and
the impact depends on TLB miss overhead that varies according to the
system configuration.

	Byungchul