Hi, In a multi-NUMA architecture, the RMM firmware is loaded to a memory of a numa. When the confidential virtual machine triggers VM_Exit, inst cache miss exists in running of code of the RMM, and an instruction needs to be fetched from the DRAM to the instruction cache. If the vCPU and RMM firmware memory do not belong to the same NUMA node, the instruction fetch delay is longer and the performance is poorer. I would like to ask if there is an optimization plan for this problem?
Hi Wuweinan, RMM itself is not aware of NUMA topology of the system. The internal per-CPU data structures of RMM are a contiguous block of memory but these accesses are few in comparison to the overall Realm VM accesses. If the NS Hypervisor can allocate the Realm VM data granules and other meta structures (like RD, REC) from memory local to the NUMA node, then the Realm accesses when scheduled on a CPU on the node would be optimal IMO.
Since RMM execution is a small slice in the overall performance of the end to end use case, we are not sure whether a more complex allocation strategy in RMM will bring a measurable performance benefit to the usecase. So currently there is no plan to optimize this in RMM.
Best Regards Soby Mathew
-----Original Message----- From: wuweinan@huawei.com wuweinan@huawei.com Sent: Monday, March 25, 2024 1:26 AM To: tf-rmm@lists.trustedfirmware.org Subject: [tf-rmm] RMM Performance Optimization in Multi-NUMA Architecture
Hi, In a multi-NUMA architecture, the RMM firmware is loaded to a memory of a numa. When the confidential virtual machine triggers VM_Exit, inst cache miss exists in running of code of the RMM, and an instruction needs to be fetched from the DRAM to the instruction cache. If the vCPU and RMM firmware memory do not belong to the same NUMA node, the instruction fetch delay is longer and the performance is poorer. I would like to ask if there is an optimization plan for this problem? _______________________________________________ tf-rmm mailing list -- tf-rmm@lists.trustedfirmware.org To unsubscribe send an email to tf-rmm-leave@lists.trustedfirmware.org
tf-rmm@lists.trustedfirmware.org