Artificial performance limitation

[Daniel van Vugt]

I think the cleanest solution would be a return to using the "IPC thread 
pool" (like in the old days). Presently we use it for receiving 
requests, but not for sending responses any more (unless frame dropping).

The challenge is only to ensure we don't reintroduce the problems we 
used to have with it being fixed in size. Some intelligent scaling is 
required.

Although longer term, a thread pool might not be required at all if we 
can come up with a reliably fast asynchronous select() implementation to 
replace the asio sockets/io_service.


On 13/11/14 11:58, Daniel van Vugt wrote:
> Pretty pictures of a stuttering server attached.
>
> Notice the CompositingFunctor where ~vector destruction is consuming 30%
> of the time, due to ~TemporaryCompositorBuffer taking 27% of the time.
>
> I think we need to move the final buffer release/response logic out of
> the compositor thread one way or another, because blocking the
> compositor thread is a very visible problem.
>
>
> On 03/11/14 08:36, Daniel van Vugt wrote:
>> This bug and its sister bug are driving me crazy:
>> https://bugs.launchpad.net/mir/+bug/1388490
>> https://bugs.launchpad.net/mir/+bug/1377872
>>
>> I can see in both cases that the frame rate ceiling is arbitrary and
>> temporary. It has nothing at all to do with the power of the host. And
>> the workaround that fixes the problem in both cases is a bit crazy.
>>
>> I've so far investigated theories around:
>>    * buffer lifetimes
>>    * Mesa/intel GL batching bugs
>>    * lock contention (locks held too long)
>>    * power management modes
>>    * Mir socket/protocol bottlenecks
>>
>> All the theories have some merit but I am not making progress. If you
>> are (un)lucky enough to be able to reproduce either bug then please join
>> in. More data points are required.
>>
>> - Daniel
>>
>
>
>