Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756751AbXLBUqa (ORCPT ); Sun, 2 Dec 2007 15:46:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754749AbXLBUqV (ORCPT ); Sun, 2 Dec 2007 15:46:21 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:48576 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754389AbXLBUqV (ORCPT ); Sun, 2 Dec 2007 15:46:21 -0500 Date: Sun, 2 Dec 2007 21:45:59 +0100 From: Ingo Molnar To: =?iso-8859-1?Q?J=F6rn?= Engel Cc: Mark Lord , Pavel Machek , Mark Lord , Thomas Gleixner , len.brown@intel.com, Andrew Morton , linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org, rjw@sisk.pl Subject: Re: [BUG] Strange 1-second pauses during Resume-from-RAM Message-ID: <20071202204559.GA28550@elte.hu> References: <20071201205456.GA8231@elte.hu> <20071201234112.GA7209@lazybastard.org> <20071202085607.GA28966@elte.hu> <20071202113143.GA9378@lazybastard.org> <20071202135711.GA20434@elte.hu> <20071202141117.GB9516@lazybastard.org> <20071202154746.GA27069@elte.hu> <20071202195501.GB10657@lazybastard.org> <20071202200722.GA12101@elte.hu> <20071202203016.GC10657@lazybastard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20071202203016.GC10657@lazybastard.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1441 Lines: 41 * J?rn Engel wrote: > > oprofile helps if you can reliably reproduce the slowdown in a loop > > or for a long amount of time, with lots of CPU utilization - and > > then it's also lower overhead. The tracer can be used to capture > > rare or complex events, and gives the full flow control and what is > > happening within the kernel. > > Such a trace would be useful indeed. But so far the patch has only > given me grief and nothing remotely like useful output. Maybe I > should simply use the complete -rt patch instead of debugging the > broken-out latency-tracer patch. to capture that trace i did not use -rt, i just patched latest -git with: http://people.redhat.com/mingo/latency-tracing-patches/latency-tracing-v2.6.24-rc3.combo.patch (this has your fixes included already) have done: echo 1 > /proc/sys/kernel/mcount_enabled and have run: ./trace-cmd sleep 1 > trace.txt http://people.redhat.com/mingo/latency-tracing-patches/trace-cmd.c to capture a 1 second trace of what the system is doing. I think your troubles are due to running it within a qemu guest - that is not a typical utilization so you are on unchartered waters. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/