Re: getnstimeofday stuck for several milliseconds?

[David Henningsson <david.henningsson@canonical.com>]

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