Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1516407imm; Sun, 27 May 2018 08:51:07 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ3eDiPZq3qSEyk0nyMbjE0JMF5BD9peTJyKgSzEOS+ieOvPZ7XI8ISObdB/dk3FBazb9iJ X-Received: by 2002:a65:611a:: with SMTP id z26-v6mr1129442pgu.61.1527436267585; Sun, 27 May 2018 08:51:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527436267; cv=none; d=google.com; s=arc-20160816; b=WTV9fgtCfEtY151dPA5Y6Zf/BYFwa2dsXXMaOUOLsBtS0KUMkk65yP0k0dt7F5o2Zr LhwLkj5k1nJ2YOc5rwzul7zZw9cXJi0nFaD5L7lr8llXVYudkrNp2tfZIuPpcsoQhJPg 8fs32k+tqm09suMyYW9UDkro6RNXtr4BfGjKBlUoMvOoBgPDRs38Amag4Dz8aq6jdiww TS/dY8ZGhxbxswcFDSeD8B5ITsrhYs7SeghBPoQEzMfYvtPF21agl8uF173Pqr5T4Ecj 0tJ+W0d4CdO5F2TbaOWztTM5G59vXyMkQUsuDb31b4SS1NGc6VD04hpiqwX6U0sog6wZ +BYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=DF5PeJCIiTdhj9RliLZu3JNRlCpLbhegtz3dnJQweNU=; b=oVPcqV7udY3J1BMy6r2YbmTGJr4s5PhAKJKoiQ55GWzOCkIGyUksxLIXVRPVx3mGw0 qRfNakxO5xGM+pO6kkuqg6756wuOaE9FpEp383fmk3stZrEEdsp23T1xL4k7E95xOMOG xWFW8ko+3O75nYAnlHPBpittkAXrnmZIgM4TC70xA1Kllyxt3O/MSvezmCjk91pPkxe+ QqavLgCycvQY5LqzgB22cQc6f69LtBtMxyccokytoQJN9ppD2xqnIdPfJLp+w9tgnajL db1lQriF/oPMsorGUQFiPTYUWmScLvx7uMQa7cB7cetwnQzuhIevUfgaPAvQLytLEX8X ZPmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y139-v6si29186658pfc.163.2018.05.27.08.50.53; Sun, 27 May 2018 08:51:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033147AbeE0Pts (ORCPT + 99 others); Sun, 27 May 2018 11:49:48 -0400 Received: from mga02.intel.com ([134.134.136.20]:28383 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032739AbeE0PqS (ORCPT ); Sun, 27 May 2018 11:46:18 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2018 08:46:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,448,1520924400"; d="scan'208";a="227741076" Received: from romley-ivt3.sc.intel.com ([172.25.110.60]) by orsmga005.jf.intel.com with ESMTP; 27 May 2018 08:46:12 -0700 From: Fenghua Yu To: "Thomas Gleixner" , "Ingo Molnar" , "H. Peter Anvin" Cc: "Ashok Raj" , "Dave Hansen" , "Rafael Wysocki" , "Tony Luck" , "Alan Cox" , "Ravi V Shankar" , "Arjan van de Ven" , "linux-kernel" , "x86" , Fenghua Yu Subject: [RFC PATCH 05/16] x86/split_lock: Use non atomic set and clear bit instructions in clear_cpufeature() Date: Sun, 27 May 2018 08:45:54 -0700 Message-Id: <1527435965-202085-6-git-send-email-fenghua.yu@intel.com> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1527435965-202085-1-git-send-email-fenghua.yu@intel.com> References: <1527435965-202085-1-git-send-email-fenghua.yu@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org x86_capability can span two cache lines depending on kernel configuration and building environment. When #AC exception is enabled for split locked accesses, clear_cpufeature() may generate #AC exception because of atomic setting or clearing bits in x86_capability. But kernel clears cpufeature only during a CPU is booting up. Therefore, there is no racing condition when clear_cpufeature() is called and no need to atomically clear or set bits in x86_capability. To avoid #AC exception caused by split lock, call non atomic __set_bit() and __clear_bit(). They are faster than atomic set_bit() and clear_bit() as well. Signed-off-by: Fenghua Yu --- arch/x86/kernel/cpu/cpuid-deps.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index 2c0bd38a44ab..b2c2a004c769 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -65,15 +65,15 @@ static const struct cpuid_dep cpuid_deps[] = { static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature) { /* - * Note: This could use the non atomic __*_bit() variants, but the - * rest of the cpufeature code uses atomics as well, so keep it for - * consistency. Cleanup all of it separately. + * Because this code is only called during boot time and there + * is no need to be atomic, use non atomic __*_bit() for better + * performance and to avoid #AC exception for split locked access. */ if (!c) { clear_cpu_cap(&boot_cpu_data, feature); - set_bit(feature, (unsigned long *)cpu_caps_cleared); + __set_bit(feature, (unsigned long *)cpu_caps_cleared); } else { - clear_bit(feature, (unsigned long *)c->x86_capability); + __clear_bit(feature, (unsigned long *)c->x86_capability); } } -- 2.5.0