linux-kernel - Re: [PATCH] x86/sgx: Replace kmap/kunmap

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: <Yz9iEwCZDa4F5pii@iweiny-desk3>
Date:   Thu, 6 Oct 2022 16:17:39 -0700
From:   Ira Weiny <ira.weiny@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>
CC:     "Fabio M. De Francesco" <fmdefrancesco@...il.com>,
        <linux-kernel@...r.kernel.org>, <linux-sgx@...r.kernel.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "Borislav Petkov" <bp@...en8.de>, <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Kristen Carlson Accardi <kristen@...ux.intel.com>
Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls

On Thu, Oct 06, 2022 at 03:29:35PM -0700, Hansen, Dave wrote:
> On 10/6/22 15:02, Fabio M. De Francesco wrote:
> > On Thursday, October 6, 2022 10:45:56 PM CEST Dave Hansen wrote:
> > Am I still missing anything fundamental?
> 
> Yes. :)
> 
> kmap() users can sleep.  That means the number of them that you need to
> keep around is unbounded.  kmap_atomic()'s fundamentally can't sleep so
> you need fewer of them.  That means that when you kunmap_atomic() you
> can use a simple, fast, CPU-local TLB flushing operation.  kunmap()
> eventually requires a big fat global TLB flush.
> 
> So, you're right.  On lowmem-only systems, kmap() *can* be cheaper than
> kmap_atomic().  But, on highmem systems there's no contest:
> kmap_atomic() is king.
> 
> That's why kmap_atomic() is and should be the default.

But in the last few years optimizing lowmem systems has been the default.  Few
care about the performance of highmem systems.

Given that we don't want to ever use kmap() nor kmap_atomic() going forward I
think this discussion is purely academic.

Ira