[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080502.144827.158329188.davem@davemloft.net>
Date: Fri, 02 May 2008 14:48:27 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: a.p.zijlstra@...llo.nl
Cc: efault@....de, elendil@...net.nl, parag.warudkar@...il.com,
mingo@...e.hu, linux-kernel@...r.kernel.org, guichaz@...oo.fr,
andi@...stfloor.org
Subject: Re: 'global' rq->clock
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Date: Fri, 02 May 2008 21:56:26 +0200
> Ok, the the below would need something that relates tick_timestamp's to
> one another.. probably sucks without it..
>
> OTOH, Andi said he was working on a fastish global sched_clock() thingy,
> Andi got a link to that code?
While I'm fine with this kind of stuff being added to constantly cope
with x86's joke of a TSC register implementation, it's starting to
become an enormous burdon for platforms where the TICK source actually
works properly.
Heck, on my Niagara2 chips, all 64 cpus use the same physical register
for the TICK source, it physically can't get desynchronized :-)
So, a way to turn all of this muck off would be much appreciated.
I'm happy to test anything on sparc64, and I'm sure the powerpc
folks are as well.
And I also heard a rumor that Peter has access to a machine with a
stable tick source for testing :-)
--
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/
Powered by blists - more mailing lists