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] [day] [month] [year] [list]
Date:   Wed, 6 Dec 2017 18:33:13 +0100
From:   Ingo Molnar <>
To:     Dave Hansen <>
Cc:     the arch/x86 maintainers <>,
        Andy Lutomirski <>,
        LKML <>,
        Linux-MM <>,
        "Kleen, Andi" <>,
        "Chen, Tim C" <>,
        Linus Torvalds <>,
        Peter Zijlstra <>
Subject: Re: x86 TLB flushing: INVPCID vs. deferred CR3 write

* Dave Hansen <> wrote:

> tl;dr: Kernels with pagetable isolation using INVPCID compile kernels
> 0.58% faster than using the deferred CR3 write.  This tends to say that
> we should leave things as-is and keep using INVPCID, but it's far from
> definitive.

Agreed, thanks for the detailed testing!

> If folks have better ideas for a test methodology, or specific workloads or 
> hardware where you want to see this tested, please speak up.

I had a look at the numbers and it all looks valid and good to me too - it's also 
the intuitive result IMHO.

I suspect there might be synthetic cache-hot workloads where the +330 cycles cost 
of INVPCID is higher than that of the extra TLB miss costs of a CR3 flush - but we 
do know that this offset is constant, while the cost of flushing all TLBs ever 
increases with the future increases of the TLB cache.



Powered by blists - more mailing lists