Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 6 Oct 2022 16:17:39 -0700
From:   Ira Weiny <ira.weiny@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
CC:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
        <linux-kernel@vger.kernel.org>, <linux-sgx@vger.kernel.org>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "Borislav Petkov" <bp@alien8.de>, <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Kristen Carlson Accardi <kristen@linux.intel.com>
Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls
Message-ID: <Yz9iEwCZDa4F5pii@iweiny-desk3>
References: <20220929160647.362798-1-kristen@linux.intel.com>
 <3694452.kQq0lBPeGt@mypc>
 <d64e6e9f-27b9-9bbb-aaf8-fca1681eada5@intel.com>
 <8124835.T7Z3S40VBb@mypc>
 <3dfccc80-e089-4915-d57e-96d26b237182@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3dfccc80-e089-4915-d57e-96d26b237182@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?m3F0YT10b0zy92/dcgBQMvo328vyp5GJff2M8yADvQVKRQhe2QEQoyvFxtwu?=
 =?us-ascii?Q?FA9iBJXWlcRw594bV57vTVdb8PodLs5Pr6V/jwBHxCMT0XGtAVO8OyASE900?=
 =?us-ascii?Q?I5/X4CgG6RhTIazQV6hUp/ZHMEbTxDbNqkERFEwFggvxmSAwXQ6m/rCJVcCu?=
 =?us-ascii?Q?VwDXSQm6yxAATb5qFKbnwAYLtvwBvVW1ApDTRV6Xx6VMkbIf6EP1n2wIWy6w?=
 =?us-ascii?Q?wJDqnEWWkT5ch80De/TEXERQAJsw7icN9rmN62AZPgi8CnpAegPSY/KEIPZP?=
 =?us-ascii?Q?8VTfaQ7Zjdn4nNXhUH+rcngGsVs8aydAdcDIEHrJRmcW8d0XffA/x7bDVCze?=
 =?us-ascii?Q?GY5HZRl0tHE+OtkuZpTkyC+j2ugz5sLvlyvIo3M9rbf233SeMD7WMUcrO5mn?=
 =?us-ascii?Q?duOgla5QF7ZgLKmtWzDL8lGSEWcuoej2ghr/ph10724A7uoLwH+od8AgSx5r?=
 =?us-ascii?Q?3TxHc2o2CX4HqO1LTK4MOJjgjZjspJ/2yIycfgOXTL5peQ3vvwshF6rkxj+f?=
 =?us-ascii?Q?63CB9/qypWONFwqlqOUQs7ilG3gVxar6h37lkT8G3jOQ9JNhKkkeNhy1WU6f?=
 =?us-ascii?Q?MFtBeylCAunkUXeEa0B88ucpi0DsHL2rrHZKsNd6a3zVFxUaDa8I7VwVD8Ot?=
 =?us-ascii?Q?0ts1qNyWk0juKTc2L4oKy8CRNg8iEm0PgCg7gej6ROGxKahhqf1sm/g6SvL+?=
 =?us-ascii?Q?7syKWoW6keuKstDO/kq/L0L0c6JEm40Mb5rrq31nJgBXtA7dF4Te01mbNjQ1?=
 =?us-ascii?Q?lPxKnZhcad7cEIJnWX1MTHCIbD6aIPL8fesDYwKDGKEjlQAJp7+P8mUMKXQW?=
 =?us-ascii?Q?0+4fbPwbGCMBg5jBQZhy8u9ZDcX5plD0OXCJyKTCuU0PYYLLGqabPua3HS0M?=
 =?us-ascii?Q?OEhIsQ8d6N4E3fWiX5gM/nIU4ts+kN/IsPekuaJWFdl7h2YSv4gw377rrL5V?=
 =?us-ascii?Q?BCly6d/Ltz+O1qlFaKeLM8MX/hoOVKbVWqrf6X3xKdCqU8rEB+IyHSfnpl8N?=
 =?us-ascii?Q?Oiyh8R4CvQJLohRKc+TJsEH2CcXPppa7yB2D+0Z1QP2yCpwp/9gUsv8fgFy/?=
 =?us-ascii?Q?WBijxU/owoTQvkjXSspqUoQsEzHld6zOOeSPRNB/GaZsmuFelQRh+3P/S79f?=
 =?us-ascii?Q?tLqKUcPP4168sg2MKZdqi6PDVXRg+LpM5bkBDnlLIdLsS4e96CwkhkTkNUSj?=
 =?us-ascii?Q?WQZBs1wF9QbST8XcIv88L3RX8toPEvf1YS+JdFiGP2wnDyAfy0JRU8PWt0YW?=
 =?us-ascii?Q?1UDhCn1MqK73dSVBk3Yx7AXfnVsw0IHeMKxQX5FR5pdbaXjP9y9j2LRhMfVK?=
 =?us-ascii?Q?W/FTFPgyHALBXjEbjlz7x+38coqCYzpg5z3TQHmIpuo5A6ZMHkk3q2bSD/l+?=
 =?us-ascii?Q?MWJfOiaLtx+vdYXQx5GoPQhkGblIiqM5LyCAfTWWUA532pom+XvLkiqe+5oh?=
 =?us-ascii?Q?vmXG2R8luSIwfnAFYUZMffI7KqJAl4STusg2SNssUHZR/AK3ZhelAOsEPLP1?=
 =?us-ascii?Q?EuntFlUvB8gkycObaUv9dhPK3V8DGWlJCXIgpzkQDiaJA9mfF+ftfhqphcX8?=
 =?us-ascii?Q?gueshDuzb/gsveWuYrD7lnYDX9HRVwUB3pnry3Oi?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5f6d642b-fae9-410c-209f-08daa7f0f95b
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6733.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2022 23:17:44.5266
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2D9FgN1ZfPU/P6TZH7NckwbanfYOI7xACdCVZrVm1tfO9rQiG0dsVOyRD/7kTOPLuyzC83bKYwu+YJf9OkAFDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR11MB6234
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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