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, 3 Mar 2022 11:59:09 -0800
From:   "Luck, Tony" <tony.luck@intel.com>
To:     "Williams, Dan J" <dan.j.williams@intel.com>
Cc:     "hdegoede@redhat.com" <hdegoede@redhat.com>,
        "markgross@kernel.org" <markgross@kernel.org>,
        "Joseph, Jithu" <jithu.joseph@intel.com>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "rostedt@goodmis.org" <rostedt@goodmis.org>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "hpa@zytor.com" <hpa@zytor.com>, "bp@alien8.de" <bp@alien8.de>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "andriy.shevchenko@linux.intel.com" 
        <andriy.shevchenko@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC 07/10] platform/x86/intel/ifs: Create kthreads for online
 cpus for scan test
Message-ID: <YiEeDfuQyqperN9x@agluck-desk3.sc.intel.com>
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

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