lkml.org 
[lkml]   [2012]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: getnstimeofday stuck for several milliseconds?
On 11/13/2012 01:15 AM, Steven Rostedt wrote:
> On Mon, 2012-11-12 at 15:53 -0800, John Stultz wrote:
>
>> Cc'ing Steven to see if he can't help understand whats going on here.
>
> I don't trust the trace...

Thanks John and Steven!

I've redone the trace with the global clock and got a different stack
trace, this time at 11 ms in total. (I don't know how much of these 11
ms are caused from the tracing overhead?)

The result is here:

http://pastebin.se/jxxqf8pt

and most of the time it seems to be these lines repeating:

compiz-1975 0.N.1 11us+: arch_flush_lazy_mmu_mode <-kmap_atomic_prot
compiz-1975 0.N.1 16us : __kunmap_atomic <-drm_clflush_page
compiz-1975 0.N.1 16us : native_flush_tlb_single <-__kunmap_atomic
compiz-1975 0.N.1 17us : arch_flush_lazy_mmu_mode <-__kunmap_atomic
compiz-1975 0.N.. 18us : drm_clflush_page <-drm_clflush_sg
compiz-1975 0.N.. 18us : kmap_atomic <-drm_clflush_page
compiz-1975 0.N.. 19us : kmap_atomic_prot <-kmap_atomic

There are also occasionally sched* tasks going on at other CPUs. If you
would excuse a layman's question - why can't we just schedule alsa-sink
on another CPU, if this one is busy with doing graphics stuff?

For reference, test kernel and test case were the same this time around
(3.7rc2, then playing a game for a few minutes).


--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic


\
 
 \ /
  Last update: 2012-11-13 10:01    [W:0.029 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site