LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Sitsofe Wheeler <sitsofe@yahoo.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: How how latent should non-preemptive scheduling be?
Date: Fri, 19 Sep 2008 16:20:05 +0200 [thread overview]
Message-ID: <1221834006.5537.3.camel@lappy.programming.kicks-ass.net> (raw)
In-Reply-To: <48D39312.9000400@yahoo.com>
On Fri, 2008-09-19 at 12:54 +0100, Sitsofe Wheeler wrote:
> Ingo Molnar wrote:
> > here's two quick howtos:
> >
> > http://redhat.com/~mingo/sched-devel.git/readme-tracer.txt
> > http://redhat.com/~mingo/sched-devel.git/howto-trace-latencies.txt
>
> These two files appear to be identical. Is this intentional?
>
> Anyway after following your instructions a putting together a small
> script to dice the output, I collated the 10 switches which took the
> longest:
>
> # Top ten longest switches
> # Rel TS Process Abs TS
> 0.122161 hald-3423 1867.821170 ***
> 0.039438 <idle>-0 1867.379054
> 0.036318 hald-3423 1867.669009
> 0.031362 <idle>-0 1868.002762
> 0.030000 hald-3423 1867.699009
> 0.028933 <idle>-0 1867.529238
> 0.028539 <idle>-0 1867.228861
> 0.028196 <idle>-0 1867.128731
> 0.027763 <idle>-0 1868.101449
> 0.027513 <idle>-0 1867.028606
>
> # tracer: sched_switch from around longest switch
> #
> # TASK-PID CPU# TIMESTAMP FUNCTION
> # | | | | |
> <idle>-0 [00] 1867.608017: 0:140:R + 3:115:S
> <idle>-0 [00] 1867.608038: 0:140:R + 3423:120:D
> <idle>-0 [00] 1867.608045: 0:140:R ==> 3:115:R
> ksoftirqd/0-3 [00] 1867.608048: 3:115:S ==> 3423:120:R
> hald-3423 [00] 1867.629350: 3423:120:R + 6096:120:S
> hald-3423 [00] 1867.632691: 3423:120:R + 3827:120:S
> hald-3423 [00] 1867.669009: 3423:120:R + 3998:120:S
> hald-3423 [00] 1867.699009: 3423:120:R + 6097:120:S
> ***hald-3423 [00] 1867.821170: 3423:120:R ==> 6096:120:R
> rhythmbox-6096 [00] 1867.821219: 6096:120:S ==> 6097:120:R
> rhythmbox-6097 [00] 1867.821262: 6097:120:R + 3826:120:S
> rhythmbox-6097 [00] 1867.821289: 6097:120:S ==> 3826:120:R
> pulseaudio-3826 [00] 1867.821332: 3826:120:R + 6097:120:S
> pulseaudio-3826 [00] 1867.821374: 3826:120:S ==> 6097:120:R
> rhythmbox-6097 [00] 1867.821380: 6097:120:S ==> 3998:120:R
> rhythmbox-3998 [00] 1867.821709: 3998:120:S ==> 3827:120:R
> pulseaudio-3827 [00] 1867.824041: 3827:120:R + 3826:120:S
>
Its actually function tracer output I'm interested in.. that shows what
all its doing to make it take 120+ms.
I thought we had a wakeup latency tracer exacty like we have preempt and
irq off latency tracers, Steve, where'd that go?
> > sounds like potential SMM triggered latencies.
>
> I have just gone away and read about the SMM (
> http://blogs.msdn.com/carmencr/archive/2005/08/31/458609.aspx ). If
> you're right there is pretty much nothing that can be done about the
> problem : (
Yeah, SMM/SMI is nasty stuff :-(
next prev parent reply other threads:[~2008-09-19 14:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.ERZTl/6uH+mhNoef5fPJKTRjJag@ifi.uio.no>
[not found] ` <fa.PtPFzP5kIJVCCov6YCewrh+o4z4@ifi.uio.no>
[not found] ` <fa.C6WSm5Rh2Nb+Qho7b0qDOZ9RPV8@ifi.uio.no>
[not found] ` <fa.ch6j4qXs/2sFpLkHz5fXrtjTR8c@ifi.uio.no>
[not found] ` <fa.Jx/Ygtm46CVRawlA6OnfYNn6cN0@ifi.uio.no>
2008-09-18 7:26 ` Sitsofe Wheeler
[not found] ` <fa.iIHgL48F3T5VAqFw3mqaf9Pzrs4@ifi.uio.no>
[not found] ` <fa.Td8xkKZKMSMghlJmEYefTRVF2kc@ifi.uio.no>
2008-09-19 11:54 ` Sitsofe Wheeler
2008-09-19 14:20 ` Peter Zijlstra [this message]
2008-09-22 11:57 ` Ingo Molnar
2008-09-22 12:07 ` Steven Rostedt
2008-09-23 6:33 ` Sitsofe Wheeler
2008-09-23 11:53 ` Ingo Molnar
2008-09-23 16:30 ` Sitsofe Wheeler
2008-09-23 19:39 ` Sitsofe Wheeler
2008-09-23 22:01 ` Sitsofe Wheeler
2008-09-27 20:48 ` Ingo Molnar
2008-09-28 20:56 ` Sitsofe Wheeler
2008-09-29 8:37 ` Ingo Molnar
2008-09-29 23:11 ` Sitsofe Wheeler
2008-09-30 11:22 ` Ingo Molnar
2008-09-30 13:18 ` Sitsofe Wheeler
2008-10-04 10:50 ` Reading EeePC900 battery info causes stalls when using SLUB (was Re: How how latent should non-preemptive scheduling be?) Sitsofe Wheeler
[not found] <fa.vMKgvqjqmYnI2J40GHoTENeYm8U@ifi.uio.no>
[not found] ` <fa.808p0ZtU9DCpeky4KfNS8Drdw9w@ifi.uio.no>
2008-09-17 21:48 ` How how latent should non-preemptive scheduling be? Sitsofe Wheeler
2008-09-17 21:54 ` Arjan van de Ven
2008-09-17 22:29 ` Sitsofe Wheeler
2008-09-18 2:42 ` Peter Zijlstra
2008-09-18 18:25 ` Sitsofe Wheeler
2008-09-19 8:44 ` Ingo Molnar
2008-09-17 21:18 Sitsofe Wheeler
2008-09-17 21:28 ` Sitsofe Wheeler
2008-09-17 21:34 ` Arjan van de Ven
2008-09-21 20:56 ` Matt Keenan
2008-09-22 6:50 ` Sitsofe Wheeler
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=1221834006.5537.3.camel@lappy.programming.kicks-ass.net \
--to=a.p.zijlstra@chello.nl \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=sitsofe@yahoo.com \
--subject='Re: How how latent should non-preemptive scheduling be?' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).