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  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:	Fri, 18 Jul 2014 22:22:50 +0200
From:	Peter Zijlstra <>
To:	John Stultz <>
Cc:	Pawel Moll <>,
	Steven Rostedt <>,
	Ingo Molnar <>,
	Oleg Nesterov <>,
	Andrew Morton <>,
	Mel Gorman <>,
	Andy Lutomirski <>,
	Stephen Boyd <>,
	Baruch Siach <>,
	Thomas Gleixner <>,
	lkml <>
Subject: Re: [RFC] sched_clock: Track monotonic raw clock

On Fri, Jul 18, 2014 at 12:46:29PM -0700, John Stultz wrote:
> On 07/18/2014 12:34 PM, Peter Zijlstra wrote:
> > On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
> >> Also, assuming we someday will merge the x86 sched_clock logic into
> >> the generic sched_clock code, we'll have to handle cases where they
> >> aren't the same.
> > I prefer that to not happen. I spend quite a bit of time and effort to
> > make the x86 code go fast, and that generic code doesn't look like fast
> > at all.
> A stretch goal then :)
> But yes, the generic sched_clock logic has really just started w/ ARM
> and is hopefully moving out to pick up more architectures. I suspect it
> will need to adapt many of your tricks from (if not a whole migration to
> some of) the x86 code. And even if the x86 code stays separate for
> optimization reasons, thats fine.

So the generic stuff seems optimized for 32bit arch, short clocks and
seems to hard assume the clock is globally consistent.

The x86 sched_clock code is optimized for 64bit, has a full 64bit clock
and cannot ever assume the thing is globally consistent (until Intel/AMD
stop making the TSC register writable -- including, and maybe
especially, for SMM).

There is just not much that overlaps there.

> But as folks try to align things like perf timestamps with time domains
> we expose to userspace, we'll have to keep some of the semantics in sync
> between the various implementations, and having lots of separate
> implementations will be a burden.

We're already there, there's about nr_arch - 5 implementations,
hopefully many trivial ones though.

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists