From: Lee Revell <rlrevell@joe-job.com>
To: Mark Knecht <markknecht@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Daniel Walker <dwalker@mvista.com>,
linux-kernel@vger.kernel.org
Subject: Re: Latency data - 2.6.14-rc3-rt13
Date: Tue, 11 Oct 2005 20:02:48 -0400 [thread overview]
Message-ID: <1129075368.7094.3.camel@mindpipe> (raw)
In-Reply-To: <5bdc1c8b0510111545n29b77010h8558a1b69c4bf12a@mail.gmail.com>
On Tue, 2005-10-11 at 15:45 -0700, Mark Knecht wrote:
> On 10/11/05, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Mark Knecht <markknecht@gmail.com> wrote:
> >
> > > > ( softirq-timer/0-3 |#0): new 3997 us maximum-latency critical section.
> > >
> > > So the root cause of this 4mS delay is the 250Hz timer. If I change
> > > the system to use the 1Khz timer then the time in this section drops,
> > > as expected, to 1mS.
> >
> > this was a bug in the critical-section-latency measurement code of x64.
> > The timer irq is the one that leaves userspace running for the longest
> > time, between two kernel calls.
> >
> > I have fixed these bugs in -rc4-rt1, could you try it? It should report
> > much lower latencies, regardless of PM settings.
> >
> > Ingo
> >
>
> Ingo,
> This test now reports much more intersting data:
>
> ( dmesg-8010 |#0): new 13 us maximum-latency critical section.
> => started at timestamp 117628604: <do_IRQ+0x29/0x50>
> => ended at timestamp 117628618: <do_IRQ+0x39/0x50>
This is the expected, correct behavior - very small maximum latency
critical sections. Do you get anything longer (say 300 usecs or more)
if you leave it running?
So far the latency tracer on my much slower system has only gone up to
123 usecs. So the bug seems to be fixed at least on i386.
Lee
next prev parent reply other threads:[~2005-10-12 0:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-10 20:16 Latency data - 2.6.14-rc3-rt13 Mark Knecht
2005-10-10 20:49 ` Daniel Walker
2005-10-10 21:12 ` Mark Knecht
2005-10-10 21:28 ` Mark Knecht
2005-10-10 21:44 ` Daniel Walker
2005-10-10 22:09 ` Mark Knecht
2005-10-10 22:28 ` Daniel Walker
2005-10-10 23:33 ` Mark Knecht
2005-10-10 23:49 ` Mark Knecht
2005-10-11 3:45 ` Mark Knecht
2005-10-11 6:46 ` Steven Rostedt
2005-10-11 8:56 ` Sven-Thorsten Dietrich
2005-10-11 11:17 ` Ingo Molnar
2005-10-11 22:45 ` Mark Knecht
2005-10-12 0:02 ` Lee Revell [this message]
2005-10-12 1:09 ` Mark Knecht
2005-10-12 1:21 ` Lee Revell
2005-10-12 1:25 ` Mark Knecht
2005-10-12 6:38 ` Steven Rostedt
2005-10-12 16:18 ` Lee Revell
2005-10-12 17:03 ` Steven Rostedt
2005-10-11 3:56 ` Matan Peled
2005-10-11 4:45 ` Mark Knecht
2005-10-11 6:14 ` Ingo Molnar
2005-10-11 7:53 ` Ingo Molnar
2005-10-10 21:39 ` Daniel Walker
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=1129075368.7094.3.camel@mindpipe \
--to=rlrevell@joe-job.com \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markknecht@gmail.com \
--cc=mingo@elte.hu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox