Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp4580pxb; Mon, 31 Jan 2022 03:52:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJyMNUgPmKeH+AAD2ySyFqgEnj+3N7FNqB4hpD1gU06k0c9UT2rFvdcfOm2W3QDln7UpjZpp X-Received: by 2002:a17:90b:f10:: with SMTP id br16mr33912272pjb.57.1643629935142; Mon, 31 Jan 2022 03:52:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643629935; cv=none; d=google.com; s=arc-20160816; b=d9kYP5rQd0AiOfK7wpPmi8Wbh4Jq345Lxxz0xNAAJ2egYwBu7IeQMpf7IJXyb2K0v0 cBhd/k9AurRKn2iJZ78hmfyqWbNFpGfRBhhhi2go7rF3npJlNbEspQnD3FkS/icyqhuE L3WfpBhfm35ApPHuJ+ciBce+dRcW6hr/glwpzQm1Z1yx0vDAg0fqfJnZVubYCDQwLNLM YWYh/N15ll1y+TEu3/d5619DCBbIvc/Cwig4lP2V92zTWcI6L59q6T74DDslR/dK29zp H40EfDqL6yhKtCZmAEjX/eJ9GHc85lB3Esg3jy3nCQCprhI7TNBylZrrAyI/G6dExOir rHXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=mbLbVL1f/nY9IQzdc+cpTldH+2iE6ToC49uNLLpEp3Y=; b=vQKusDh7xocawGLNLHVI1SrryY8nBalHu7ajIUdoYSLm8iV/evL6ojSD1+pxpRuTLr mzl4oWdz4KY7PyHH6fGmoHGlQ16Ab5QQNi8/Pf6+RIYoL5tttWq6tW2uuHs6JSNcduyI v3iqUgyHbuEa5jLy5YS9UUn9pncBQzgzOyewrW3HtEMVhqBzx1J1oV4AGmuG+p31Ys2N r8Az2Iz//gix/qC4x/+dSN34YEhTgjRbTbX3SuOE+j7xkTGqVibNC0mpqGXDcvqlzZcw PufN9hz3/yCXaHFV80DyGHWZmnq6XhuQx8+FmfbP00cbxHAhYMysaQyN9F01R3EYAqjj L6Zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TeokYAJi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ng9si10754437pjb.26.2022.01.31.03.52.04; Mon, 31 Jan 2022 03:52:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TeokYAJi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348298AbiA2AQy (ORCPT + 99 others); Fri, 28 Jan 2022 19:16:54 -0500 Received: from mga03.intel.com ([134.134.136.65]:12777 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235979AbiA2AQy (ORCPT ); Fri, 28 Jan 2022 19:16:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643415414; x=1674951414; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ib0+KQqGLzivGEVkAmTrUFi1+1QJrYHHbJ0KiLhCotI=; b=TeokYAJi4mE/I3Lz5iGaOkGWLFPdzaMt5pYszfxuGH0/5StvscYQTy64 m6f6Ve5EG4oK1+zludPYvmvCXCo82FL7OHA/prGd6FPGNs7DUoQgTzSPI GRqHqZuGRVQFtmT7MVo4mEYGvNb9ApOdkJmcjBWePhD6BdY35dKdGzKhr 5c1CX9nDGKCCDss33yvjKuvcVdPKkNt8BeMYpHYmj2BrtIe4WNE0+okm6 wk2KPygZz5cyy8dDDDRGsI4xaOxR68LIelCQ9liq+SIjT1s9YWMbl0sUt h+J/wadfMn6r/vXSFlvPKD28mGqUW7PlBp/3+mW9q4VweKvXLE8sn9bJw Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10241"; a="247170668" X-IronPort-AV: E=Sophos;i="5.88,325,1635231600"; d="scan'208";a="247170668" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jan 2022 16:16:53 -0800 X-IronPort-AV: E=Sophos;i="5.88,325,1635231600"; d="scan'208";a="536342085" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jan 2022 16:16:53 -0800 Date: Fri, 28 Jan 2022 16:16:53 -0800 From: Ira Weiny To: Dave Hansen Cc: Dave Hansen , "H. Peter Anvin" , Dan Williams , Fenghua Yu , Rick Edgecombe , linux-kernel@vger.kernel.org Subject: Re: [PATCH V8 14/44] x86/pkeys: Introduce pks_write_pkrs() Message-ID: <20220129001653.GM785175@iweiny-DESK2.sc.intel.com> References: <20220127175505.851391-1-ira.weiny@intel.com> <20220127175505.851391-15-ira.weiny@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 28, 2022 at 04:12:06PM -0800, Dave Hansen wrote: > On 1/27/22 09:54, ira.weiny@intel.com wrote: > > Writing to MSR's is inefficient. Even though the underlying > > WRMSR(MSR_IA32_PKRS) is not serializing (see below), writing to the MSR > > unnecessarily should be avoided. This is especially true when the value > > of the PKS protections is unlikely to change from the default often. > > This probably needs some context. > > The most important pks_write_pkrs() user is in the scheduler, right? This is also used during exceptions, twice. Those are probably more important. > > So, this is really about optimizing that scheduler code for the common > case where, even when changing threads, the PKRS value does not change. > > Can you explain a bit why you expect that to be the common case? Yes. Ira