From: Waiman Long <waiman.long@hpe.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
X86 ML <x86@kernel.org>, Jiang Liu <jiang.liu@linux.intel.com>,
Borislav Petkov <bp@suse.de>, Andy Lutomirski <luto@kernel.org>,
Scott J Norton <scott.norton@hpe.com>,
Douglas Hatch <doug.hatch@hpe.com>,
Randy Wright <rwright@hpe.com>
Subject: Re: [PATCH] x86/hpet: Reduce HPET counter read contention
Date: Fri, 8 Apr 2016 16:07:58 -0400 [thread overview]
Message-ID: <57080F9E.7010904@hpe.com> (raw)
In-Reply-To: <CALCETrWzS0MGTtDLecuwZa4ikvGAYHwWf-4gDjti=DV6gb1V+g@mail.gmail.com>
On 04/07/2016 08:13 PM, Andy Lutomirski wrote:
> On Thu, Apr 7, 2016 at 8:07 AM, Waiman Long<waiman.long@hpe.com> wrote:
>> On 04/07/2016 12:58 AM, Andy Lutomirski wrote:
>>> Reading the HPET is so slow that all the atomic ops in the world won't
>>> make a dent. Why not just turn this optimization on unconditionally?
>>>
>>> --Andy
>>
>> I am constantly on the alert that we should not introduce regression on
>> lesser systems like a single socket machine with a few cores. That is why I
>> put the check to conditionally enable this optimization. I have no issue of
>> taking that out and let it be the default as long as no one object.
>>
> Agreed. I just suspect it's actually faster on all systems.
>
> This reminds me -- I need to send out my patch to disable the vdso
> HPET code, which will make your change more effective. I'll cc you.
>
I am going to send an updated patch which reduces CPU threshold to 32 as
well as adding kernel parameter to explicitly enable or disable this
optimization. In this way, you can enable it on system with less CPUs,
if necessary.
Cheers,
Longman
prev parent reply other threads:[~2016-04-08 20:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 14:02 [PATCH] x86/hpet: Reduce HPET counter read contention Waiman Long
2016-04-07 4:58 ` Andy Lutomirski
2016-04-07 15:07 ` Waiman Long
2016-04-08 0:13 ` Andy Lutomirski
2016-04-08 20:07 ` Waiman Long [this message]
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=57080F9E.7010904@hpe.com \
--to=waiman.long@hpe.com \
--cc=bp@suse.de \
--cc=doug.hatch@hpe.com \
--cc=hpa@zytor.com \
--cc=jiang.liu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=rwright@hpe.com \
--cc=scott.norton@hpe.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