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;
MIME-Version: 1.0
References: <1547673522-226408-1-git-send-email-fenghua.yu@intel.com>
 <1547673522-226408-6-git-send-email-fenghua.yu@intel.com> <CALCETrWCJAzRj7BUBX=O2qdHXucNWz=z0uEQ5asskTbw8CGW5w@mail.gmail.com>
 <20190221192424.GA158428@romley-ivt3.sc.intel.com> <3E5A0FA7E9CA944F9D5414FEC6C712209D877F3A@ORSMSX106.amr.corp.intel.com>
In-Reply-To: <3E5A0FA7E9CA944F9D5414FEC6C712209D877F3A@ORSMSX106.amr.corp.intel.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Sun, 24 Feb 2019 11:45:35 -0800
Message-ID: <CALCETrVJsCAWYSnUE+Ju_VmZfZBUBwUq-uFjV9=Vy+wddtJVCw@mail.gmail.com>
Subject: Re: [PATCH v2 1/3] x86/cpufeatures: Enumerate user wait instructions
To:     "Yu, Fenghua" <fenghua.yu@intel.com>
Cc:     Andy Lutomirski <luto@kernel.org>, "Xu, Tao3" <tao3.xu@intel.com>,
        "Liu, Jingqi" <jingqi.liu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
        H Peter Anvin <hpa@zytor.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Feb 21, 2019 at 2:57 PM Yu, Fenghua <fenghua.yu@intel.com> wrote:
>
> > From: Fenghua Yu [mailto:fenghua.yu@intel.com]
> > On Wed, Feb 20, 2019 at 10:37:27PM -0800, Andy Lutomirski wrote:
> > Or to simplify the situation, how about we still use zero as global max=
 wait
> > time (i.e. no limitation for global wait time) as implemented in this p=
atch
> > set? User can still change the value to any value based on their usage.=
 Isn't
> > this a right way to take care of any usage?
>
> Plus, if scheduler timers works, umwait will be forced time out by timer =
in HZ anyway.

Indeed.  But, on some configs, the scheduler timer intentionally will
*not* fire.

>
> Only for case without scheduler timer, sysadmin may need to set a small m=
ax umwait time to force timout. But in this case (real time), I doubt user =
app really wants to call umwait to save power with long latency of waking u=
p from umwait. So likely in this case, user app won't call umwait and there=
 is no usage to set a small value for max umwait time.

I don't really know why an application would use umwait at all.  About
the only legitimate use I can think of is to treat it as a somewhat
power-saving variant of REP NOP.  What I want to avoid is the case
where it works dramatically differently on NO_HZ_FULL systems as
compared to everything else.  Also, UMWAIT may behave a bit
differently if the max timeout is hit, and I'd like that path to get
exercised widely by making it happen even on default configs.

So I propose setting the timeout to either 100 microseconds or 100k
"cycles" by default.  In the event someone determines that they save
materially more power or gets materially better performance with a
longer timeout, we can revisit the value.

--Andy