From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26050 invoked by alias); 23 Sep 2008 20:09:49 -0000 Received: (qmail 26043 invoked by uid 22791); 23 Sep 2008 20:09:48 -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 20:09:10 +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 m8NK8Q7a014921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 22:08:27 +0200 Date: Tue, 23 Sep 2008 20:09:00 -0000 From: Thomas Gleixner To: Masami Hiramatsu cc: Linus Torvalds , Mathieu Desnoyers , Martin Bligh , Linux Kernel Mailing List , Steven Rostedt , darren@dvhart.com, "Frank Ch. Eigler" , systemtap-ml Subject: Re: Unified tracing buffer In-Reply-To: <48D94BA8.9030106@redhat.com> Message-ID: References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <48D7F5E8.3000705@redhat.com> <33307c790809221313s3532d851g7239c212bc72fe71@mail.gmail.com> <48D81B5F.2030702@redhat.com> <33307c790809221616h5e7410f5gc37c262d83722111@mail.gmail.com> <48D832B6.3010409@redhat.com> <33307c790809221712x4fbd9781u958c98d4585e92a9@mail.gmail.com> <48D901FE.5060604@redhat.com> <20080923150410.GA28341@Krystal> <48D90B84.4030905@redhat.com> <48D921B3.2060809@redhat.com> <48D93CAF.8070000@redhat.com> <48D94BA8.9030106@redhat.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/msg00785.txt.bz2 On Tue, 23 Sep 2008, Masami Hiramatsu wrote: > 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 ! > > Thank you for analyzing! :-) > Hmm, then could I fix that by fixing my dsdt...? You can limit c-states so you dont do down to the C3 state, but there is a trade off vs. power saving. Lets wait for Martins magic TSC patches first :) tglx