linux-kernel - Re: [PATCH v2] tile: avoid using clocksource

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Nov 2016 12:29:45 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Chris Metcalf <cmetcalf@...lanox.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Salman Qazi <sqazi@...gle.com>, Paul Turner <pjt@...gle.com>,
        Tony Lindgren <tony@...mide.com>,
        Steven Miao <realmz6@...il.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2] tile: avoid using clocksource_cyc2ns with absolute
 cycle count

On Wed, Nov 16, 2016 at 12:16 PM, Chris Metcalf <cmetcalf@...lanox.com> wrote:
> On 11/16/2016 2:59 PM, John Stultz wrote:
>>
>> In your earlier patch, you mentioned this was similar to 4cecf6d401a0
>> ("sched, x86: Avoid unnecessary overflow in
>> sched_clock"). It might be better to actually try to use similar logic
>> there, to make sure the performance impact is minimal.
>
>
> This was the first thing I looked at when I saw the mult_frac()
> implementation.  The modulus operations are indeed converted to
> bitmasks and the divides to shifts.  We do have to do two multiplies
> instead of one, but that's basically the worst of the cost.
>
> Change 4cecf6d401a0 results in essentially identical code for x86 as
> this proposed change does for tile.  In fact a follow-on change by
> Salman introduced mult_frac() and switched to using it, so it was
> identical at that point.
>
> PeterZ (cc'ed) then improved it to use __int128 math via
> mul_u64_u32_shr(), but that doesn't help tile; we only do one multiply
> instead of two, but the multiply is handled by an out-of-line call to
> __multi3, and the sched_clock() function ends up about 2.5x slower as
> a result.
>
> Thanks for thinking about this!

Heh. Thanks for the history lesson and apologies for my forgetfulness. :)

thanks
-john