linux-kernel - Re: [PATCH] x86/hpet: Reduce HPET counter read contention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 8 Apr 2016 16:07:58 -0400
From:	Waiman Long <waiman.long@....com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Jiang Liu <jiang.liu@...ux.intel.com>,
	Borislav Petkov <bp@...e.de>,
	Andy Lutomirski <luto@...nel.org>,
	Scott J Norton <scott.norton@....com>,
	Douglas Hatch <doug.hatch@....com>,
	Randy Wright <rwright@....com>
Subject: Re: [PATCH] x86/hpet: Reduce HPET counter read contention

On 04/07/2016 08:13 PM, Andy Lutomirski wrote:
> On Thu, Apr 7, 2016 at 8:07 AM, Waiman Long<waiman.long@....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