From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15960 invoked by alias); 23 Sep 2008 19:42:45 -0000 Received: (qmail 15952 invoked by uid 22791); 23 Sep 2008 19:42:44 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from www.tglx.de (HELO www.tglx.de) (62.245.132.106) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Sep 2008 19:42:09 +0000 Received: from localhost (www.tglx.de [127.0.0.1]) by www.tglx.de (8.13.8/8.13.8/TGLX-2007100201) with ESMTP id m8NJfepx009504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 21:41:41 +0200 Date: Tue, 23 Sep 2008 19:42:00 -0000 From: Thomas Gleixner To: Martin Bligh cc: Masami Hiramatsu , Linus Torvalds , Mathieu Desnoyers , Linux Kernel Mailing List , Steven Rostedt , darren@dvhart.com, "Frank Ch. Eigler" , systemtap-ml Subject: Re: Unified tracing buffer In-Reply-To: <33307c790809231238m1e80fef4rce8a80722ff245f1@mail.gmail.com> Message-ID: References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <33307c790809221712x4fbd9781u958c98d4585e92a9@mail.gmail.com> <48D901FE.5060604@redhat.com> <20080923150410.GA28341@Krystal> <48D90B84.4030905@redhat.com> <48D921B3.2060809@redhat.com> <48D93CAF.8070000@redhat.com> <33307c790809231238m1e80fef4rce8a80722ff245f1@mail.gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.93.2/8314/Tue Sep 23 02:50:20 2008 on www.tglx.de X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on www.tglx.de Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00781.txt.bz2 On Tue, 23 Sep 2008, Martin Bligh wrote: > On Tue, Sep 23, 2008 at 12:36 PM, Thomas Gleixner wrote: > > On Tue, 23 Sep 2008, Masami Hiramatsu wrote: > >> # cat /sys/devices/system/cpu/cpu0/cpuidle/state3/usage > >> 171210 > > > > C3 stops the TSC. So depending on how many C3 entries you have on the > > different cores, your TSCs will drift apart. Some BIOSes do even a > > lousy job trying to fixup the TSCs on exit from C3, which makes things > > even worse. > > > >> C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000016] duration[00000000000000000000] > >> C2: type[C2] promotion[--] demotion[--] latency[001] usage[00037969] duration[00000000000024288003] > >> C3: type[C3] promotion[--] demotion[--] latency[057] usage[00171818] duration[00000000001881257636] > >> > >> Could these help you? > > > > Yup, explains your TSC observation. Nothing we can do about. Broken by > > system design :( Welcome in the wonderful world of Inhell/BIOS/ACPI ! > > We have linux patches that sync the TSC on exit_idle. I'll see if I can get > Michael to send them out. Are you sure that they sync it precicely enough that there is no user space observable way of time going backwards between cores ? Thanks, tglx