Messages in this thread | | | Date | Tue, 13 Nov 2012 09:26:51 +0100 | From | David Henningsson <> | Subject | Re: 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
| |