[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071115193424.GA31691@elte.hu>
Date: Thu, 15 Nov 2007 20:34:24 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Mark Lord <lkml@....ca>
Cc: Pavel Machek <pavel@....cz>, Mark Lord <liml@....ca>,
Thomas Gleixner <tglx@...utronix.de>, len.brown@...el.com,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
rjw@...k.pl
Subject: Re: [BUG] Strange 1-second pauses during Resume-from-RAM
* Mark Lord <lkml@....ca> wrote:
>> Can you try nohz=off highres=off? Strange stuff is happening with
>> nohz.
>
> (added Ingo to CC: list: maybe this is some weird interaction with CFS
> and jiffies being reset to 0 on resume ??)
hm, CFS should have no impact here. To see what's happening you could
try to use the latency tracer of the -rt patch and do a cross-resume
trace.
pick up the latest latency tracer patch from:
http://redhat.com/~mingo/private/latency-tracer-v2.6.24-rc2-git5-combo.patch
apply it and enable CONFIG_FUNCTION_TRACING, then pick up trace-cmd.c:
http://redhat.com/~mingo/private/trace-cmd.c
and do something like:
./trace-cmd pm-suspend > trace.txt
or:
./trace-cmd /bin/bash -c "echo ram > /sys/power/state" > trace.txt
this should trigger suspend - then you should do the resume. If
everything goes well then trace.txt should contain a pretty large trace
of all the stuff we do during a suspend+resume.
and wait for such a pause and send us the resulting trace.txt.
if it's an SMP box then first do:
echo 1 > /proc/sys/kernel/trace_all_cpus
to get a global trace. Let me know if something doesnt work with this
scheme.
Ingo
-
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