linux-kernel - RE: Direct rdtsc call side-effect

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]

Message-ID: <a39d90e45212461bb31738b7156b60a6@AcuMS.aculab.com>
Date:   Mon, 5 Jun 2023 15:54:22 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Thomas Gleixner' <tglx@...utronix.de>,
        Muhammad Usama Anjum <usama.anjum@...labora.com>,
        Jonathan Corbet <corbet@....net>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "Guilherme G. Piccoli" <gpiccoli@...lia.com>
CC:     Steven Noonan <steven@...inklabs.net>,
        "kernel@...labora.com" <kernel@...labora.com>
Subject: RE: Direct rdtsc call side-effect

From: Thomas Gleixner <tglx@...utronix.de>
> Sent: 05 June 2023 15:44
> 
> On Mon, Jun 05 2023 at 10:27, David Laight wrote:
> > It has to be said that using it as a time source was fundamentally
> > a bad idea.
> 
> Too bad you weren't around many moons ago and educated us on that. That
> would have saved us lots of trouble and work.

Indeed :-)
I do remember thinking the TSC was really a good time source when
I first saw it being done about 30 years ago.

> 
> > Sometimes (eg micro benchmarks) you really want a TSC.
> > You can extract one from the performance counters, but it is hard,
> > root only, and the library functions have high and variable overhead.
> 
> Interesting view that high end databases are considered micro benchmarks
> which need root access.

I'm thinking of benchmarking the IP checksum code where you are
trying to find out how many bytes/clock the loop is doing.
On recent x86-64 the theoretical limit (without fighting AVX) 1s 16
bytes/clock, I've measured 12, 8 is relatively easy.
(The current asm code runs at 4 on older cpu, doesn't get
much above 6 at all.)

What happens is that the cpu frequency speeds up as soon as the
test starts but the TSC frequency stays constants.
So you can only use the TSC to measure time, not execution speed.

Run enough copies of 'while :; do :; done &' to make all but one
cpu busy and the cpus all speed up giving completely different
TSC counts for short loops.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)