All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Andy Lutomirski <luto@kernel.org>, Fenghua Yu <fenghua.yu@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	H Peter Anvin <hpa@zytor.com>, Ashok Raj <ashok.raj@intel.com>,
	Ravi V Shankar <ravi.v.shankar@intel.com>,
	linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v2 3/3] x86/umwait: Control umwait maximum time
Date: Sun, 20 Jan 2019 19:12:17 +0000	[thread overview]
Message-ID: <ae8d5a07-9fbc-7c76-fa88-ff2718696686@citrix.com> (raw)
In-Reply-To: <CALCETrVenEpKH5O=Z6J+faWTcdZpa1xx4-dYwdWu1OSEDyiUWw@mail.gmail.com>

On 17/01/2019 00:00, Andy Lutomirski wrote:
> On Wed, Jan 16, 2019 at 1:24 PM Fenghua Yu <fenghua.yu@intel.com> wrote:
>> IA32_UMWAIT_CONTROL[31:2] determines the maximum time in TSC-quanta
>> that processor can stay in C0.1 or C0.2.
>>
>> The maximum time value in IA32_UMWAIT_CONTROL[31-2] is set as zero which
>> means there is no global time limit for UMWAIT and TPAUSE instructions.
>> Each process sets its own umwait maximum time as the instructions operand.
>>
>> User can specify global umwait maximum time through interface:
>> /sys/devices/system/cpu/umwait_control/umwait_max_time
>> The value in the interface is in decimal in TSC-quanta. Bits[1:0]
>> are cleared when the value is stored.
>>
>> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
>> ---
>>  arch/x86/include/asm/msr-index.h |  2 ++
>>  arch/x86/power/umwait.c          | 42 +++++++++++++++++++++++++++++++-
>>  2 files changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
>> index b56bfecae0de..42b9104fc15b 100644
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -62,6 +62,8 @@
>>  #define MSR_IA32_UMWAIT_CONTROL                0xe1
>>  #define UMWAIT_CONTROL_C02_BIT         0x0
>>  #define UMWAIT_CONTROL_C02_MASK                0x00000001
>> +#define UMWAIT_CONTROL_MAX_TIME_BIT    0x2
>> +#define UMWAIT_CONTROL_MAX_TIME_MASK   0xfffffffc
>>
>>  #define MSR_PKG_CST_CONFIG_CONTROL     0x000000e2
>>  #define NHM_C3_AUTO_DEMOTE             (1UL << 25)
>> diff --git a/arch/x86/power/umwait.c b/arch/x86/power/umwait.c
>> index 95b3867aac1e..4a1a507d3bb7 100644
>> --- a/arch/x86/power/umwait.c
>> +++ b/arch/x86/power/umwait.c
>> @@ -10,6 +10,7 @@
>>  #include <asm/msr.h>
>>
>>  static int umwait_enable_c0_2 = 1; /* 0: disable C0.2. 1: enable C0.2. */
>> +static u32 umwait_max_time; /* In TSC-quanta. Only bits [31:2] are used. */
>>  static DEFINE_MUTEX(umwait_lock);
>>
>>  /* Return value that will be used to set umwait control MSR */
>> @@ -20,7 +21,8 @@ static inline u32 umwait_control_val(void)
>>          * When bit 0 is 1, C0.2 is disabled. Otherwise, C0.2 is enabled.
>>          * So value in bit 0 is opposite of umwait_enable_c0_2.
>>          */
>> -       return ~umwait_enable_c0_2 & UMWAIT_CONTROL_C02_MASK;
>> +       return (~umwait_enable_c0_2 & UMWAIT_CONTROL_C02_MASK) |
>> +              umwait_max_time;
>>  }
>>
>>  static ssize_t umwait_enable_c0_2_show(struct device *dev,
>> @@ -61,8 +63,46 @@ static ssize_t umwait_enable_c0_2_store(struct device *dev,
>>
>>  static DEVICE_ATTR_RW(umwait_enable_c0_2);
>>
>> +static ssize_t umwait_max_time_show(struct device *kobj,
>> +                                   struct device_attribute *attr, char *buf)
>> +{
>> +       return sprintf(buf, "%u\n", umwait_max_time);
>> +}
>> +
>> +static ssize_t umwait_max_time_store(struct device *kobj,
>> +                                    struct device_attribute *attr,
>> +                                    const char *buf, size_t count)
>> +{
>> +       u32 msr_val, max_time;
>> +       int cpu, ret;
>> +
>> +       ret = kstrtou32(buf, 10, &max_time);
>> +       if (ret)
>> +               return ret;
>> +
>> +       mutex_lock(&umwait_lock);
>> +
>> +       /* Only get max time value from bits [31:2] */
>> +       max_time &= UMWAIT_CONTROL_MAX_TIME_MASK;
>> +       /* Update the max time value in memory */
>> +       umwait_max_time = max_time;
>> +       msr_val = umwait_control_val();
>> +       get_online_cpus();
>> +       /* All CPUs have same umwait max time */
>> +       for_each_online_cpu(cpu)
>> +               wrmsr_on_cpu(cpu, MSR_IA32_UMWAIT_CONTROL, msr_val, 0);
>> +       put_online_cpus();
>> +
>> +       mutex_unlock(&umwait_lock);
>> +
>> +       return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(umwait_max_time);
>> +
>>  static struct attribute *umwait_attrs[] = {
>>         &dev_attr_umwait_enable_c0_2.attr,
>> +       &dev_attr_umwait_max_time.attr,
>>         NULL
>>  };
> You need something to make sure that newly onlined CPUs get the right
> value in the MSR.  You also need to make sure you restore it on resume
> from suspend.  Something like cpu_init() might be the right place.
>
> Also, as previously discussed, I think we should set the default to
> something quite small, maybe 100 microseconds.  IMO the goal is to
> pick a value that is a high enough multiple of the C0.2 entry+exit
> latency that we get most of the power and SMT resource savings while
> being small enough that no one things that UMWAIT is more than a
> glorified, slightly improved, and far more misleading version of REP
> NOP.
>
> Andrew, would having Linux default to a small value do much to
> mitigate your concerns that UMWAIT is problematic for hypervisors?

Sadly no - not really.

Being an MSR, there is no way the guest kernel is having unfiltered
access, so the hypervisor can set whatever bound it wishes.

For any non-trivial wait period, it would be better for the system as a
whole to switch to a different vcpu, but the semantics don't allow for
that.  Shortening the timeout just results in userspace taking over
again, and most likely concluding that there was an early wakeup and
going back to sleep.

More useful semantics would be something similar to pause-loop-exiting
so we can swap contexts while the processor is logically idle in userspace.

~Andrew

  parent reply	other threads:[~2019-01-20 19:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 21:18 [PATCH v2 0/3] x86/umwait: Enable user wait instructions Fenghua Yu
2019-01-16 21:18 ` [PATCH v2 1/3] x86/cpufeatures: Enumerate " Fenghua Yu
2019-01-16 21:18 ` [PATCH v2 2/3] x86/umwait: Setup umwait C0.2 state Fenghua Yu
2019-01-16 23:51   ` Andy Lutomirski
2019-01-16 21:18 ` [PATCH v2 3/3] x86/umwait: Control umwait maximum time Fenghua Yu
2019-01-17  0:00   ` Andy Lutomirski
2019-01-17  0:07     ` Fenghua Yu
2019-01-17  0:30       ` Andy Lutomirski
2019-01-17  2:06         ` Fenghua Yu
2019-01-20 19:12     ` Andrew Cooper [this message]
2019-01-20 21:40       ` Andy Lutomirski
2019-02-08 18:51       ` Yu, Fenghua
2019-01-16 21:18 ` [PATCH v2 0/3] x86/umwait: Enable user wait instructions Fenghua Yu
2019-01-16 21:18 ` [PATCH v2 1/3] x86/cpufeatures: Enumerate " Fenghua Yu
2019-02-21  6:37   ` Andy Lutomirski
2019-02-21  9:22     ` Peter Zijlstra
2019-02-21 19:24     ` Fenghua Yu
2019-02-21 22:57       ` Yu, Fenghua
2019-02-24 19:45         ` Andy Lutomirski
2019-02-26 19:53           ` Fenghua Yu
2019-02-22  2:09       ` Tao Xu
2019-02-26 20:41     ` Fenghua Yu
2019-01-16 21:18 ` [PATCH v2 2/3] x86/umwait: Setup umwait C0.2 state Fenghua Yu
2019-01-16 21:18 ` [PATCH v2 3/3] x86/umwait: Control umwait maximum time Fenghua Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae8d5a07-9fbc-7c76-fa88-ff2718696686@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.