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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
