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.
pgpWDOn5HE0Yr.pgp
Description: PGP signature
