LinuxPPC-Dev Archive on
 help / color / Atom feed
From: Thomas Gleixner <>
To: Andy Lutomirski <>
Cc:, Arnd Bergmann <>,
	X86 ML <>, LKML <>,
	"open list:MIPS" <>,
	Paul Mackerras <>,
	Andrew Lutomirski <>,
	Vincenzo Frascino <>,
	linuxppc-dev <>,
	linux-arm-kernel <>
Subject: Re: [RFC PATCH v4 08/11] lib: vdso: allow fixed clock mode
Date: Thu, 16 Jan 2020 22:07:51 +0100
Message-ID: <> (raw)
In-Reply-To: <>

Andy Lutomirski <> writes:
> On Thu, Jan 16, 2020 at 12:14 PM Thomas Gleixner <> wrote:
>> Some architectures have a fixed clocksource which is known at compile
>> time and cannot be replaced or disabled at runtime, e.g. timebase on
>> PowerPC. For such cases the clock mode check in the VDSO code is
>> pointless.
> I wonder if we should use this on x86 bare-metal if we have
> sufficiently invariant TSC.  (Via static_cpu_has(), not compiled in.)
> Maybe there is no such x86 machine.

There might be some, but every time I started to trust the TSC a bit
more someone reported the next variant of brokenness.

Admittedly it has become better at least up to two sockets.

For a start we could do that when the TSC is considered reliable, which
is the case when:

  - The TSC is the only available clocksource

  - tsc=reliable is on the kernel command line

> I really really want Intel or AMD to introduce machines where the TSC
> pinky-swears to count in actual nanoseconds.

and is guaranteed to be synchronized across any number of sockets/cpus
and has an enforcable protection against BIOS writers.

Ideally it'd have a writeable MSR attached which allows us to tweak the
frequency in the PPM range via NTP/PTP.

Guess how long quite some people including Linus and myself are asking
for this?

I know that Linus started bitching about the TSC before me, but it's
already a bit over 20 years on my side when I first talked to Intel and
AMD about the requirements for a reliable clocksource.

Just to set the time lines straight.

Constant frequency TSC surfaced on Intel in 2006 with the Core brand and
on AMD in 2007 with Barcelona (Fam 10h).

In 2008 the first TSC surfaced which was not affected by C-States and 5
years later in 2013 some Atoms came out where TSC even worked accross

The > 2 socket issue is still not resolved AFAICT, but we got at least
the TSC ADJUST MSR around 2012 which allowed us for the first time to
reliably detect and mitigate BIOS wreckage.

All the years I was envy on architectures which had simple designed and
just reliably working timers forever.

So now you can extrapolate how long it will take until you get your
pinky-swearing pony :)



  reply index

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 17:58 [RFC PATCH v4 00/11] powerpc: switch VDSO to C implementation Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 01/11] powerpc/64: Don't provide time functions in compat VDSO32 Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 02/11] powerpc/vdso: Switch VDSO to generic C implementation Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 03/11] lib: vdso: only read hrtimer_res when needed in __cvdso_clock_getres() Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 04/11] powerpc/vdso: simplify __get_datapage() Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 05/11] lib: vdso: allow arches to provide vdso data pointer Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 06/11] powerpc/vdso: provide inline alternative to __get_datapage() Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 07/11] powerpc/vdso: provide vdso data pointer from the ASM caller Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 08/11] lib: vdso: allow fixed clock mode Christophe Leroy
2020-01-16 20:13   ` Thomas Gleixner
2020-01-16 20:19     ` Andy Lutomirski
2020-01-16 21:07       ` Thomas Gleixner [this message]
2020-01-16 17:58 ` [RFC PATCH v4 09/11] powerpc/vdso: override __arch_vdso_capable() Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 10/11] lib: vdso: Allow arches to override the ns shift operation Christophe Leroy
2020-01-16 19:47   ` Andy Lutomirski
2020-01-16 19:57     ` Thomas Gleixner
2020-01-16 20:20       ` Andy Lutomirski
2020-01-29  7:14         ` Thomas Gleixner
2020-01-29  7:26           ` Christophe Leroy
2020-01-16 17:58 ` [RFC PATCH v4 11/11] powerpc/32: provide vdso_shift_ns() Christophe Leroy
2020-01-17  8:58 ` [RFC PATCH v4 00/11] powerpc: switch VDSO to C implementation Segher Boessenkool
2020-01-17  9:26   ` Christophe Leroy
2020-01-20 14:56   ` Christophe Leroy
2020-01-20 15:19     ` Segher Boessenkool
2020-01-20 17:08       ` Christophe Leroy
2020-01-20 17:27         ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LinuxPPC-Dev Archive on

Archives are clonable:
	git clone --mirror linuxppc-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linuxppc-dev linuxppc-dev/ \
	public-inbox-index linuxppc-dev

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone