From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753962AbYIYQdL (ORCPT ); Thu, 25 Sep 2008 12:33:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752763AbYIYQc5 (ORCPT ); Thu, 25 Sep 2008 12:32:57 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:51380 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752658AbYIYQc4 (ORCPT ); Thu, 25 Sep 2008 12:32:56 -0400 Date: Thu, 25 Sep 2008 12:32:54 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Mathieu Desnoyers cc: Ingo Molnar , Martin Bligh , Linus Torvalds , Peter Zijlstra , Martin Bligh , linux-kernel@vger.kernel.org, Thomas Gleixner , Andrew Morton , prasad@linux.vnet.ibm.com, "Frank Ch. Eigler" , David Wilder , hch@lst.de, Tom Zanussi , Steven Rostedt Subject: Re: [RFC PATCH 1/3] Unified trace buffer In-Reply-To: <20080925162315.GA649@Krystal> Message-ID: References: <33307c790809241403w236f2242y18ba44982d962287@mail.gmail.com> <1222339303.16700.197.camel@lappy.programming.kicks-ass.net> <8f3aa8d60809250733q70561e6agfa3b00da83773e9f@mail.gmail.com> <1222354409.16700.215.camel@lappy.programming.kicks-ass.net> <33307c790809250825u567d3680w682899c111e10ed6@mail.gmail.com> <20080925153635.GA12840@elte.hu> <20080925162315.GA649@Krystal> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 25 Sep 2008, Mathieu Desnoyers wrote: > The problem with sched_clock is that it gives a 1 HZ timestamp accuracy > for events happening across different CPUs. Within this 1 HZ range, it > uses the TSC and clip when it reaches a max. Good enough for scheduler > or for tracing events on a single CPU, but I think it is not exactly > what we need to reorder events happening across CPUs. > Hmm, sched_clock gives ns accuracy unless the tsc is disabled. And in that case, we don't have any CPU clock :-/ -- Steve