On 25/08/15 16:58, Rahul Khandelwal (Rahul Khandelwal) wrote:
Dear Sarbojit,
Agreed with your point, thanks for raising it..
There was one issue in the total no of interrupt count in the previous chart preparation, actually the total no of interrupt is equal to the interrupt sent to Idle core.
On an average we are saving more than 25% of the IPIs sent to big domain CPUs. I just updated the below mentioned chart with the related data.
I would argue that a reduction on the total number of IPIs is not a suitable metric to evaluate the real impact on "application performance".
*Case 1: *
*Video Recording – IPI reduced by 23.5%*
*Case 2:*
Browsing and Audio(Background) – IPI reduced by 33.11%**Case 3: *
Subway Surfer game – IPI reduced by 23.80%*
All these use cases should produce an application specific performance metric, e.g. average frame rate or frame encoding time. I understand that it could be tricky to identify such a metric, however if we can measure the impact of the propose patch on application specific metrics the evaluation will be much more complete.
For example, it would be really nice to verify that the propose patch (with the integration into hmp_up_migration) could produce a sensible reduction on the responsiveness of the scheduler to migrate all the new-big tasks to big CPUs.
If possible, it is of interest a measure of the energy consumption required to complete a use-case, with and without the patch. Indeed, usually we like to evaluate HMP modifications in such a way to avoid sensible regressions in terms of power/performance figures.
Cheers Patrick