From: Ingo Molnar <mingo@elte.hu>
To: Kevin Winchester <kjwinchester@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arjan van de Ven <arjan@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: Latency issues with x86.git
Date: Thu, 14 Feb 2008 07:07:58 +0100 [thread overview]
Message-ID: <20080214060758.GC29509@elte.hu> (raw)
In-Reply-To: <47B39577.3020603@gmail.com>
* Kevin Winchester <kjwinchester@gmail.com> wrote:
> Hi Ingo,
>
> I have encountered (a handful of times in the past few months) some
> real interactivity problems on my system. Moving the mouse or typing
> a key on the keyboard takes around a second to show any response.
> Once I perform a reboot, the problem is gone again. I am currently
> running x86.git mm branch, but I switch between that branch, mainline
> git, and mm kernels, so I cannot guarantee on which trees I have or
> have not seen the problem.
please try sched-devel.git, which has both the latest scheduler fixes,
and also the new "ftrace" latency tracing framework that can be used to
trace various latency problems. You can pick up sched-devel.git via:
http://people.redhat.com/mingo/sched-devel.git/README
firstly, there's a chance that sched-devel.git solves the problem - in
that case please report it.
if it doesnt, then you can trace various latencies via these:
CONFIG_FTRACE=y
CONFIG_IRQSOFF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
just enable them, boot into the new kernel and mount debugfs:
mount -t debugfs nodev /debug
and then you can select one of the tracers (that have been enabled in
the .config) via /debug/tracing/* files. The usage of these files should
be self-explaining - if any of them wasnt then please let us know and
we'll make the "first quick glance experience" better :)
the one interesting to you would be the "wakeup" tracer. Enable it, and
if you echo 0 into /debug/tracing/tracing_max_latency it starts tracking
the worst-case delay experienced on your system and should start
reporting them to the syslog.
if you encounter any problems during these steps then please let us know
- this code is quite fresh so expect some rough edges.
Ingo
prev parent reply other threads:[~2008-02-14 6:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-14 1:12 Latency issues with x86.git Kevin Winchester
2008-02-14 6:07 ` Ingo Molnar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080214060758.GC29509@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=arjan@infradead.org \
--cc=kjwinchester@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.