linux-kernel - Re: [PATCH 2/2] x86/tsc_sync: Add synchronization overhead to tsc adjustment

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]

Message-ID: <87czhymql2.ffs@tglx>
Date:   Sun, 03 Apr 2022 12:03:21 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Waiman Long <longman@...hat.com>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        "H. Peter Anvin" <hpa@...or.com>, Feng Tang <feng.tang@...el.com>,
        Bill Gray <bgray@...hat.com>,
        Jirka Hladky <jhladky@...hat.com>,
        Waiman Long <longman@...hat.com>
Subject: Re: [PATCH 2/2] x86/tsc_sync: Add synchronization overhead to tsc
 adjustment

On Mon, Mar 14 2022 at 15:46, Waiman Long wrote:
> As stated in the comment of check_tsc_sync_target():
>
>   The adjustment value is slightly off by the overhead of the
>   sync mechanism (observed values are ~200 TSC cycles), but this
>   really depends on CPU, node distance and frequency. So
>   compensating for this is hard to get right.
>
> That overhead, however, can cause the tsc adjustment to fail after 3
> test runs as can be seen when booting up a hot 4-socket Intel CooperLake
> system:
>
> [    0.034090] TSC deadline timer available
> [    0.008807] TSC ADJUST compensate: CPU36 observed 95626 warp. Adjust: 95626
> [    0.008807] TSC ADJUST compensate: CPU36 observed 74 warp. Adjust: 95700
> [    0.974281] TSC synchronization [CPU#0 -> CPU#36]:
> [    0.974281] Measured 4 cycles TSC warp between CPUs, turning off TSC clock.
> [    0.974281] tsc: Marking TSC unstable due to check_tsc_sync_source failed
>
> To prevent this tsc adjustment failure, we need to estimate the sync
> overhead which will be at least an unlock operation in one cpu followed
> by a lock operation in another cpu.
>
> The measurement is done in check_tsc_sync_target() after stop_count
> reached 2 which is set by the source cpu after it re-initializes the sync
> variables causing the lock cacheline to be remote from the target cpu.
> The subsequent time measurement will then be similar to latency between
> successive 2-cpu sync loop in check_tsc_warp().
>
> Interrupt should not yet been enabled when check_tsc_sync_target() is

Interrupts _ARE_ not enabled.

> called. However some interference may have caused the overhead estimation
> to vary a bit.  With this patch applied, the measured overhead on the
> same CooperLake system on different reboot runs varies from 104 to 326.

Hmm.

> [    0.008807] TSC ADJUST compensate: CPU36 observed 95626 warp. Adjust: 95626
> [    0.008807] TSC ADJUST compensate: CPU36 observed 74 warp. Adjust: 95700
> [    0.974281] Measured 4 cycles TSC warp between CPUs, turning off TSC clock.
> [    0.974281] tsc: Marking TSC unstable due to check_tsc_sync_source failed

Can you please provide the output after your changes? It's hard to tell
what effect adding the lock compensation has. Ideally from several runs
for both patched and unpatched.

Also if the compensation value is at the upper end and the real overhead
is way lower then the validation run might end up with the opposite
result. I'm a bit worried about this variation.

Thanks,

        tglx