Hi Brian,

Thanks for looking at the performance data. We refer to the method you give and come to similar conclusions.

- Between 1.1 and 1.7, we made a considerable number of adjustments, so the performance has also improved with these adjustments. Due to the large content and differences, it is difficult to conduct a detailed analysis of this improvement.

- The increase in cycles from 1.7 to 1.8 is caused by the merging of some phased patches. The patch that directly affects performance are here: FF-M API uses signals to drive the partition scheduling instead of controlling partition context directly.

- Because we are improving the internal logic of SPM to achieve better layering and abstraction, for practical reasons We cannot directly launch major changes, but can only merge small changes in stages. These small changes will undoubtedly have some impact on runtime performance within a certain period of time. We plan to complete the entire improvement process as soon as possible in the future. Theoretically, these local performance degradations will be naturally improved after the improvement.

- We may need to find a way to trace performance in the future.

Hope that can explain your concern, if you have further questions, please feel free to contact, thank you.

Best Regards

Jianliang Shen

From: David Hu via TF-M <tf-m@lists.trustedfirmware.org>
Sent: 05 May 2023 09:51
To: Quach, Brian <brian@ti.com>; Jamie Fox <Jamie.Fox@arm.com>; Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: psa_call performance

Hi Brian,

Thanks a lot for the clarification.

Best regards,

Hu Ziji

From: Quach, Brian <brian@ti.com>
Sent: Friday, May 5, 2023 12:09 AM
To: David Hu <David.Hu@arm.com>; Jamie Fox <Jamie.Fox@arm.com>; Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: RE: psa_call performance

Hi David,

I was using isolation level 1 for all so the latest performance figures should be correct:

-DTFM_PROFILE=profile_medium \

-DTFM_ISOLATION_LEVEL=1 \

-DCMAKE_BUILD_TYPE=Release \

Regards,
Brian

From: David Hu <David.Hu@arm.com>
Sent: Thursday, May 4, 2023 12:46 AM
To: Quach, Brian <brian@ti.com>; Jamie Fox <Jamie.Fox@arm.com>; Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] RE: psa_call performance

Hi Brian,

Thanks for the profiling data.

Please also note that CoreIPC selected Isolation level 1 while Profile Medium selects Isolation level 2. It will also impact the performance.

RelWithDebInfo was still supported in TF-M v1.7.0. It is not assigned a dedicated build type config file but it should not affect the build. Can you please take another try?

Best regards,

Hu Ziji

From: Quach, Brian via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, May 3, 2023 3:26 AM
To: Jamie Fox <Jamie.Fox@arm.com>; Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: psa_call performance

Thanks for spotting that Jamie! That fixed my issue. I was using “RelWithDebInfo” in v1.1 and changed to “Debug” for v1.7 since RelWithDebInfo was no longer an option. Call times are all improved in v1.7 over v1.1 as expected when using “Release” build type.

V1.8 is a bit worse than V1.7 though.

Psa_connect() call time in cycles:

TF-M version	Psa_connect() in cycles
1.1	3406
1.7	2872
1.8	3130

Psa_version() call time in cycles:

TF-M version	Psa_version() in cycles
1.1	343
1.7	389
1.8	500

Psa_call() call time in cycles: 1 invec, 3 outvec

TF-M version	Psa_call() in cycles
1.1	4406
1.7	3404
1.8	3722

Regards,
Brian

From: Jamie Fox <Jamie.Fox@arm.com>
Sent: Tuesday, May 2, 2023 11:09 AM
To: Quach, Brian <brian@ti.com>; Ken Liu <Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] RE: psa_call performance

Hi Brian,

I think the old ConfigCoreIPC is broadly similar to medium profile with isolation level set to 1. But I noticed in your v1.1 build logs that it is being built with optimization at -O3, whereas in v1.7 you have -DCMAKE_BUILD_TYPE=Debug which implies -O0. If you change the v1.7 build type to -DCMAKE_BUILD_TYPE=Release then that will get you an optimized -O3 build comparable to the v1.1 one.

Kind regards,

Jamie