Mir protocol code uses too much CPU (24%) vs rendering of graphics (75%)

[Daniel van Vugt]

The Mir protocol code uses too much CPU (24%) vs rendering of graphics (75%).

My intuition is that we should be spending all our time rendering, and not sucking up any significant CPU cycles on the protocol logic.

[Daniel van Vugt (vanvugt)]

Just FYI, you can divide up Mir's server profile results fairly cleanly in two by looking at inclusive cycles:
75% mir::compositor:: ...
24% boost::asio:: ...

If you assume that:
  (1) there is no boost::asio code called from under mir::compositor; and
  (2) there is no mir::compositor code call from under boost::asio
then they are logically separate regions of the server.

[The proof of (2) is that 24 < 75 and therefore can't be including the mir::compositor stuff]

[Daniel van Vugt (vanvugt)]

Hmm, actually with our new(ish) callback system in BufferQueue there probably is boost::asio code being called by mir::compositor (on compositor buffer release we send the freed buffer to the client immediately). But that might not make the problem description terribly inaccurate still.

[kevin gunn (kgunn72)]

so is this really a problem in the boost::asio isn't efficient ?
also, rather than percentages, can you post the average times of the split? curious, i mean if the time values are in absolute terms small then 25% is maybe not that bad.

[Daniel van Vugt (vanvugt)]

I can't make conclusive comments on boost::asio other than it's complex and seems to have very deep call stacks when it does anything. Although that's probably partly Mir's fault.

Sorry, but only relative percentages are available when profiling because absolute percentage is always up around 100%. And I think it's reasonable to say 25% for the protocol is too much for sending messages only 60 times per second when you compare it to the amount of work the graphics system is doing millions of times per second. But there was more evidence than that...

When I last did a direct comparison between /alternatives/ and Mir, I found their load on libGL was about equal. However Mir's total CPU usage was higher and the only obvious diff was the protocol layer. "Alternative" protocols seemed to use a much lower amount of CPU (<5%) relative to the graphics load. Sorry I can't find where I wrote all that down.

[Daniel van Vugt (vanvugt)]

That's not to say that changing protocol library would immediately help. If enough of the bottleneck was in the Mir frontend code that sits of top of that then it would be Mir that needs optimizing and not the protocol itself. Needs further analysis...

[kevin gunn (kgunn72)]

if you have relative % dwell times. I don't think you can draw conclusions without stating the following.
GPU chipset id
GPU clock
emif bus width
emif clock
CPU chipset id
CPU clock
as well as, what exactly is being drawn/processed on the gpu....# of pixels? # of shader operations?
Are you sure that the 25% doesn't include any idle time at all ?

[Daniel van Vugt (vanvugt)]

Last time I did a fair comparison with Weston it was running the same app (glmark2), although Weston was doing so under the Wayland X layer and still had lower CPU than Mir. So we need to improve...

As for idle time, definitely not. Callgrind does not report idle time, only real CPU time consumed by instructions. I often wish callgrind could report idle time too, but it can't.

[Cemil Azizoglu (cemil-azizoglu)]

25% sounds huge. Marking this as high so it can get attention.

[Daniel van Vugt (vanvugt)]

Incomplete. We need fresh stats.

[Launchpad Janitor (janitor)]

[Expired for Mir because there has been no activity for 60 days.]