lkml.org 
[lkml]   [2016]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@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

\
 
 \ /
  Last update: 2016-04-08 22:41    [W:0.061 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site