linux-kernel - what is the better method to do tsc synchronized check?

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

Message-ID: <AANLkTi=HB7s-VpMAZmNBPgvQadtN9tg91pFY-=atAWsM@mail.gmail.com>
Date:	Wed, 16 Mar 2011 22:56:25 -0400
From:	Luming Yu <luming.yu@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: what is the better method to do tsc synchronized check?

Hi there,

I tested two different methods to do TSC sync check on a Sandy Bridge system.
The first TSC sync check method is from upstream -38-rc that considers
TSC is synced.
The second TSC sync check method is from a 2.6.18 based  kernel that
considers TSC
is NOT synced on the Sandy Bridge system. (I modified sync_tsc() to
just test (not modify TSC) on
the cpu being tested.)

[root@...el-sugarbay-DO-01 kernel]# dmesg | grep -i synchroniz
CPU 1: synchronized TSC with CPU 0 (last diff 29 cycles, maxerr 276 cycles)
CPU 2: synchronized TSC with CPU 0 (last diff 32 cycles, maxerr 280 cycles)
CPU 3: synchronized TSC with CPU 0 (last diff 31 cycles, maxerr 284 cycles)

Do you guy think we need to take 2.6.18-based tsc sync testing method
rather than the current one in upstream?

Any inputs are appreciated.

Thanks
Luming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/