From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA5EEC433FE for ; Wed, 12 Oct 2022 15:50:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229627AbiJLPu0 (ORCPT ); Wed, 12 Oct 2022 11:50:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229790AbiJLPuZ (ORCPT ); Wed, 12 Oct 2022 11:50:25 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40C8113D15; Wed, 12 Oct 2022 08:50:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 40E96CE1CBC; Wed, 12 Oct 2022 15:50:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0D52C433C1; Wed, 12 Oct 2022 15:50:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665589819; bh=+gtutM/sDsmZtehVItKJH/vQ3u/GKRsWlIbIFKVnlqc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oA29ihYU6RyV6B4EjVtRg3DaUcmYNt2E3CtvlLD9SQ1SD0cU1dWoPy30tdgh/8Epk 9K9DxCcvdXfPp6oVSwyH8ZtlrJDc3ua6IT+7MmYv6CXtklV1Wt1gMGfcWjZZ654A2C 0ebBEh7ITOJqbgNlMsIe35McLh6oj+Kd3VKmQn9qc4vPBLl4am0QPDWmCogNqiBCiO 33zis6V8emINQmxxNGJj9xpdM1KeOguPQa0+FA3NFYI6q1HGSJW4GBl7PyPzp7RbnD 50NlxV7D5VDvtldTQcRpUh6Qm9b7+stTuqsbdxk9xpy/TvPWZ2hzDuDRxEPnNlKFkX PI5NqxPSKit5Q== Date: Wed, 12 Oct 2022 18:50:15 +0300 From: Jarkko Sakkinen To: Dave Hansen Cc: Ira Weiny , Kristen Carlson Accardi , linux-kernel@vger.kernel.org, linux-sgx@vger.kernel.org, Dave Hansen , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" Subject: Re: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls Message-ID: References: <20220929160647.362798-1-kristen@linux.intel.com> <711f8036-787a-571e-1c0d-1a258175ebb2@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Wed, Oct 12, 2022 at 05:50:19PM +0300, Jarkko Sakkinen wrote: > On Wed, Oct 12, 2022 at 07:13:26AM -0700, Dave Hansen wrote: > > On 10/12/22 00:15, Jarkko Sakkinen wrote: > > > There's no data to show that this change would be useful to do. > > > > Jarkko, I think the overall transition to kmap_local_page() is a good > > one. It is a superior API and having it around will pave the way for > > new features. I don't think we should demand 'data' for each and every > > one of these. > > > > Please take a look around the tree and see how other maintainers are > > handling these patches. They're not limited to SGX. > > Sure, I'll take a look for comparison. Yeah, I think it is pretty solid idea. Looking at the decription: "It is not necessary to disable page faults or preemption when using kmap calls, so replace kmap_atomic() and kunmap_atomic() calls with more the more appropriate kmap_local_page() and kunmap_local() calls." We did not pick kmap_atomic() because it disables preeemption, i.e. it was not a "design choice". I'd rather phrase this as along the lines: "Migrate to the newer kmap_local_page() interface from kmap_atomic() in order to move away from per-CPU maps to pre-task_struct maps. This in effect removes the need to disable preemption in the local CPU while kmap is active, and thus vastly reduces overall system latency." Can be improved or written completely otherwise. I just wrote it in the way that I had understood the whole deal in the first place. BR, Jarkko