Message-ID: <57080F9E.7010904@hpe.com>
Date: Fri, 8 Apr 2016 16:07:58 -0400
From: Waiman Long <waiman.long@hpe.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
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
References: <1459951324-53339-1-git-send-email-Waiman.Long@hpe.com> <CALCETrWhbsASNkpYW3DL-c76bTdE2rEmcimn6TunQL87Kx0XuA@mail.gmail.com> <570677BD.1000800@hpe.com> <CALCETrWzS0MGTtDLecuwZa4ikvGAYHwWf-4gDjti=DV6gb1V+g@mail.gmail.com>
In-Reply-To: <CALCETrWzS0MGTtDLecuwZa4ikvGAYHwWf-4gDjti=DV6gb1V+g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2016 20:08:03.9271 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0309
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1101
Lines: 26

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