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 31E25C433F5 for ; Thu, 3 Mar 2022 19:59:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235683AbiCCT76 (ORCPT ); Thu, 3 Mar 2022 14:59:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235678AbiCCT74 (ORCPT ); Thu, 3 Mar 2022 14:59:56 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1D9719CCC8; Thu, 3 Mar 2022 11:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646337550; x=1677873550; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Pwhtk1GrrqE/4VynDFryxgHiiPKn9d6coiqO1HnGW5Q=; b=Jj8P/Zy5EOtwhxQnbeJD9jTMAuvKkvB+vn4VJdhIrY8E/ZfDt8HCpqMc 9A5EV28QpCAUJ1ST27kr3x8rpUEs2qawQrHMQ6liC0t4uU7+okuJC2vyG +tUt/tvQthPXOHAVKQXdlAvlTKH/hOGOxZHOB6YaT9FMaEnN2UIlG4Ab5 hDB2+KHhABfpvqLFMKgeuPlRR85Q1u3yQNl0Za+xk4FlO58eK+EiM78pC GvLKHJGcpzkThyT1qvC9kFYkh17in7AUwbSDnv8SyhycDu5+LpEVO1Ecx uWp6jfa89lEb+yKEL9ZIPyurC//CXKpz2xsMCcSIO3JKR85YF9SJd0pcL Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10275"; a="251373167" X-IronPort-AV: E=Sophos;i="5.90,153,1643702400"; d="scan'208";a="251373167" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 11:59:10 -0800 X-IronPort-AV: E=Sophos;i="5.90,153,1643702400"; d="scan'208";a="630922010" Received: from agluck-desk3.sc.intel.com ([172.25.222.60]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2022 11:59:10 -0800 Date: Thu, 3 Mar 2022 11:59:09 -0800 From: "Luck, Tony" To: "Williams, Dan J" Cc: "hdegoede@redhat.com" , "markgross@kernel.org" , "Joseph, Jithu" , "corbet@lwn.net" , "Raj, Ashok" , "dave.hansen@linux.intel.com" , "patches@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "mingo@redhat.com" , "rostedt@goodmis.org" , "Shankar, Ravi V" , "tglx@linutronix.de" , "platform-driver-x86@vger.kernel.org" , "linux-doc@vger.kernel.org" , "hpa@zytor.com" , "bp@alien8.de" , "gregkh@linuxfoundation.org" , "andriy.shevchenko@linux.intel.com" , "x86@kernel.org" Subject: Re: [RFC 07/10] platform/x86/intel/ifs: Create kthreads for online cpus for scan test Message-ID: References: <20220301195457.21152-1-jithu.joseph@intel.com> <20220301195457.21152-8-jithu.joseph@intel.com> <09b5b05018a8600ca8fab896790ab16827c80e4e.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09b5b05018a8600ca8fab896790ab16827c80e4e.camel@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Wed, Mar 02, 2022 at 08:17:32PM -0800, Williams, Dan J wrote: > What is this requirement to try to synchronize CPU execution? Comments > should explain the "why", the code usually explains the "what". I need to put some more bits into the Documentation/x86/ifs.rst because if I had explained the IFS feature better there, you wouldn't have had to ask this (and some other questions). IFS works on one CORE at a time. But with HT enabled there are two logical CPUs that are on that core. Entering IFS test mode is done by all HT threads writing to the ACTIVATE_SCAN MSR "together". The microcode for that MSR will make the first logical CPU to write wait for a while. User can choose how many cycles to wait with some of the bits in the value written to the MSR ... in this driver we hard coded 5 milli-seconds. That seemed plenty to allow for the bottom half of interrupts, or a perf NMI to knock the HT threads a little bit out of sync with each other. So the code flow when running a test is to wake the kthreads for the logical CPUs that share the core. The threads may wake at different times, so there is the software sync to get them close enough. Then comes the loop to execute the test ... it is a loop because the core may not complete all "chunks" in one ACTIVATE_SCAN MSR write ... if it doesn't, the loop restarts execution from the chunk where IFS execution stopped. Interrupts are only blocked during the ACTIVATE_SCAN to increase the chances of completion. But preemption is disabled for the whole loop so that the threads won't get too far out of sync. -Tony