From: Fenghua Yu <fenghua.yu@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Fenghua Yu <fenghua.yu@intel.com>, Ingo Molnar <mingo@redhat.com>,
H Peter Anvin <hpa@zytor.com>, Ashok Raj <ashok.raj@intel.com>,
Alan Cox <alan@linux.intel.com>,
Ravi V Shankar <ravi.v.shankar@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [RFC PATCH 4/8] cpuidle: Set up maximum umwait time and umwait states
Date: Tue, 19 Jun 2018 08:46:27 -0700 [thread overview]
Message-ID: <20180619154627.GB112652@romley-ivt3.sc.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1806191059040.1692@nanos.tec.linutronix.de>
On Tue, Jun 19, 2018 at 11:03:22AM +0200, Thomas Gleixner wrote:
> On Fri, 15 Jun 2018, Fenghua Yu wrote:
> > By default C0.2 is enabled so user wait can save more power but wakeup
> > time is slower. In some cases e.g. real time, user wants to disable C0.2
> > so that user wait saves less power but wakeup time is faster.
>
> Why is this default enabled?
Current hardware implementation enables C0.2 by default. But I'm
not sure future every hardware always enables it by default.
In kernel, init code enforces to enable C0.2 globally by default.
Each umwait or tpause instruction will specify which state (C0.1 or C0.2)
to use during wait depending on user's decision. And a sysfs interface
allows user to disable C0.2 globally during run time.
Is this right arrangement?
>
> > A new "/sys/devices/system/cpu/cpuidle/umwait_disable_c0_2" file is
> > created to allow user to check if C0.2 is enabled or disabled and also
> > allow user to enable or disable C0.2. Value "1" in the file means C0.2 is
> > disabled. Value "0" means C0.2 is enabled.
>
> Can we please use straight forward positive logic and have a enable file?
Sure. I will do that.
>
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * umwait.c - control user wait
>
> Please remove these pointless file references. They get stale before its merged.
Sure. I will remove these.
>
> > + *
> > + * Copyright (c) 2018, Intel Corporation.
> > + * Fenghua Yu <fenghua.yu@intel.com>
> > + */
> > +/*
> > + * umwait.c adds control of user wait states that user enters through user wait
> > + * instructions umwait or tpause.
>
> umwait.c adds something?
I will change to "umwait.c controls user wait states that user enters..."?
>
> > + */
> > +#include <linux/cpu.h>
> > +#include <asm/msr.h>
> > +
> > +static int umwait_disable_c0_2;
> > +static DEFINE_MUTEX(umwait_lock);
> > +
> > +static ssize_t umwait_disable_c0_2_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + return sprintf(buf, "%d\n", umwait_disable_c0_2);
> > +}
> > +
> > +static ssize_t umwait_disable_c0_2_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t count)
> > +{
> > + int disable_c0_2, cpu, ret;
> > + u32 msr_val;
> > +
> > + ret = kstrtou32(buf, 10, &disable_c0_2);
> > + if (ret)
> > + return ret;
> > + if (disable_c0_2 != 1 && disable_c0_2 != 0)
> > + return -EINVAL;
> > +
> > + mutex_lock(&umwait_lock);
> > + umwait_disable_c0_2 = disable_c0_2;
> > + /*
> > + * No global umwait maximum time limit (0 in bits 31-0).
> > + * Enable or disable C0.2 based on global setting (bit 0) on all CPUs.
> > + */
> > + msr_val = umwait_disable_c0_2 & UMWAIT_CONTROL_C02_MASK;
>
> That mask is there because the variable can only have 0 and 1 as content....
You are right, the variable can only have 0 or 1. Is it ok to have the mask?
>
> > + for_each_online_cpu(cpu)
> > + wrmsr_on_cpu(cpu, MSR_IA32_UMWAIT_CONTROL, msr_val, 0);
>
> This lacks protection against CPU hotplug.
You are right. I will add protection.
>
> > + mutex_unlock(&umwait_lock);
> > +
> > + return count;
>
> Thanks,
>
> tglx
Thanks.
-Fenghua
next prev parent reply other threads:[~2018-06-19 15:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-16 3:06 [RFC PATCH 0/8] x86: Enable a few new instructions Fenghua Yu
2018-06-16 3:06 ` [RFC PATCH 1/8] x86/cpufeatures: Enumerate MOVDIRI instruction Fenghua Yu
2018-06-19 8:57 ` Thomas Gleixner
2018-06-19 21:36 ` Fenghua Yu
2018-06-19 22:32 ` Thomas Gleixner
2018-06-19 22:35 ` Fenghua Yu
2018-06-25 16:13 ` David Laight
2018-06-16 3:06 ` [RFC PATCH 2/8] x86/cpufeatures: Enumerate MOVDIR64B instruction Fenghua Yu
2018-06-16 3:06 ` [RFC PATCH 3/8] x86/cpufeatures: Enumerate UMONITOR, UMWAIT, and TPAUSE instructions Fenghua Yu
2018-06-16 3:06 ` [RFC PATCH 4/8] cpuidle: Set up maximum umwait time and umwait states Fenghua Yu
2018-06-19 9:03 ` Thomas Gleixner
2018-06-19 15:46 ` Fenghua Yu [this message]
2018-06-16 3:06 ` [RFC PATCH 5/8] x86/umwait.c: Add sysfs interface to show tsc_khz Fenghua Yu
2018-06-19 9:08 ` Thomas Gleixner
2018-06-19 15:11 ` Fenghua Yu
2018-06-16 3:06 ` [RFC PATCH 6/8] x86/lib_direct_store.h: Add APIs for direct store instructions Fenghua Yu
2018-06-19 8:47 ` Thomas Gleixner
2018-06-16 3:06 ` [RFC PATCH 7/8] x86/lib_user_wait.h: Add APIs for user wait instructions Fenghua Yu
2018-06-19 9:12 ` Thomas Gleixner
2018-06-19 22:27 ` Fenghua Yu
2018-06-19 22:34 ` Thomas Gleixner
2018-06-19 22:36 ` Fenghua Yu
2018-06-16 3:06 ` [RFC PATCH 8/8] selftests/x86: Self test for the APIs in lib_direct_store.h and lib_user_wait.h 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=20180619154627.GB112652@romley-ivt3.sc.intel.com \
--to=fenghua.yu@intel.com \
--cc=alan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®