View Single Post
Old 03-14-2019, 02:12 AM   #8
HadrienG
Human being with feelings
 
Join Date: Mar 2019
Posts: 7
Default

Here's a nicer profile that was acquired on a cleaner system (nothing but a maximized REAPER window around, aimlessly looping through a few MIDI tracks), and with the few extra debug symbols, which when put together allowed me to also get perf to show me kernel-side overhead

But maybe let's start by showing the breakdown by process, which is the only one that will not be affected by REAPER's lack of debugging symbols and can be 100% trusted:

Code:
  Overhead      Pid:Command
    49,17%        0:swapper
    26,60%     2392:cinnamon
     4,96%     3271:reaper/libjack
     4,48%      347:irq/26-xhci_hcd
     2,65%     3258:reaper
     2,59%     1682:X
     1,82%     3272:reaper/cs_midio
     1,43%      162:kworker/u8:6+ev
     1,07%     3243:jackd
     0,79%     1353:ntpd
     0,75%        9:ksoftirqd/0
     0,61%     3274:reaper/mediaafx
     0,59%     3308:perf
     0,53%     1280:kworker/1:5-eve
     0,45%     1689::1689
     0,23%     3273:reaper/mediaafx
     0,20%     3276:reaper/mediaafx
     0,18%     3275:reaper/mediaafx
     0,18%     2419:cinnamon:cs0
     0,15%      368:irq/27-amdgpu
     0,12%      369:gfx
The toplevel "swapper" thing that we can see now is the kernel idle task. It's spinning the CPU while waiting for work, processing CPU clock ticks, and scheduling the running programs. Nothing unusual here:

Code:
-   49,17%    49,17%        0:swapper
   - 48,72% secondary_startup_64
      - 40,57% start_secondary
         - cpu_startup_entry
            - do_idle
               - 39,49% cpuidle_enter_state
                    34,18% intel_idle
                  + 2,98% apic_timer_interrupt
                  + 2,10% ret_from_intr
      - 8,16% start_kernel
         - cpu_startup_entry
            - do_idle
               - 6,80% cpuidle_enter_state
                    6,62% intel_idle
               - 1,24% schedule_idle
                  - __sched_text_start
There is a little bit of cinnamon overhead which I missed before, because it does not have debugging symbols (or perf failed to get to them). Hard to say if it's linked to the issue at hand:

Code:
-   26,60%    26,60%     2392:cinnamon
   +→22,57% _start cinnamon
   - 1,34% 0xffffffffffffffff unknown
      +→0,76% glibtop_get_cpu_s libgtop-2.0.so.11.0.0
   - 0,97% 0x7fb789b6b9af libclutter-1.0.so.0.2600.2
       →_clutter_context_get_show_fps libclutter-1.0.so.0.2600.2
   - 0,79% 0x563cf932ceaf [heap]
       →0,79% _cogl_get_texture_unit libcogl.so.20.4.2
If you take the kernel-side overhead into account, you can see that the CPU overhead split is a bit less even that it was before. We see more drawing overhead now that we account for the kernel side of things, because a lot of drawing work is done there. We can also get a more nuanced view of the event processing stuff:

Code:
-   22,57%     0,00%  cinnamon         libglib-2.0.so.0.5800.3             [.] g_main_context_iterate.isra.26
   - 22,57% g_main_context_iterate.isra.26
      - 14,00% g_main_context_dispatch
         - 13,68% clutter_clock_dispatch
            - 13,61% _clutter_stage_do_update
               + 13,57% clutter_stage_cogl_redraw
      - 6,10% g_main_context_prepare
           2,99% g_source_iter_next
         - 1,09% gdk_event_source_prepare
            + 1,08% XPending
         - 0,79% message_queue_prepare
            + dbus_connection_get_dispatch_status
      - 2,38% g_main_context_check
         - 1,25% gdk_event_source_check
            + 1,24% XPending
           1,04% g_source_iter_next
And we can see more detail of the draw stuff too if we feel so inclined, all the way down to the user-side driver library and underlying kernel facilities.

All that extra precision does not change my general diagnosis though: this thing is crunching so much CPU because it is doing a suspicious lot of suspiciously complex graphic refreshes.
HadrienG is offline   Reply With Quote