On 6/2/26 08:19, abdelrahman elbehery wrote:
Ping
On Mon, 18 May 2026, 12:58 pm Abdelrahman Elbehery, <[email protected]
<mailto:[email protected]>> wrote:
Profiling showed g_hash_table_lookup as a hot spot when running TCG
plugins that log all CPU registers (e.g. execlog with reg=*).
Replace it with a direct array index to avoid lookup overhead.
Signed-off-by: Abdelrahman Elbehery <[email protected]
<mailto:[email protected]>>
---
While profiling (via callgrind) a TCG plugin that logs all the CPU registers
(very identical to execlog with reg=*) i noticed that arm_gdb_get_sysreg is
a hot spot,
mostly while calling g_hash_table_lookup. Probably this is due to some
hashtable collision
that is handleded by glib internally.
Currently each DynamicGDBFeatureInfo item holds keys for cp_regs, and the
keys are always
used to retrieve the ARMCPRegInfo pointer.
By replacing the keys array with a GPtrArray, we now just access reg info
directly from
the given index.
The benchmarking was done on c2d-highcpu-16 (16 vCPUs, 32 GB memory) GCP
Setup was to run qemu-system-aarch64 against a buildroot kernel and rootfs
with and without the patch mostly using:
--plugin contrib/plugins/libstoptrigger.so,icount=2000000
--plugin contrib/plugins/libexeclog.so,reg=*
-M virt -cpu cortex-a710 -smp 1
Benchmark showed ~15% performance gain when hashtable is not used.
For benchmarking, i used hyperfine with 3 warmup rounds and 10 iterations
each.
---
target/arm/cpu.h | 6 +++---
target/arm/gdbstub.c | 28 ++++++++++++++++------------
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index
15a13b929276dad161032b61ba51ebbce7eeebc6..8816e94e3f8271ad403e77f6182fdb8cee31c527
100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -121,15 +121,15 @@
* DynamicGDBFeatureInfo:
* @desc: Contains the feature descriptions.
* @data: A union with data specific to the set of registers
- * @cpregs_keys: Array that contains the corresponding Key of
- * a given cpreg with the same order of the cpreg
+ * @cpregs_regs: Array that contains the corresponding Register info
pointer
+ * of a given cpreg with the same order of the cpreg
* in the XML description.
This will not work, because each ARMCPU has separate cpreg info structures, and these
structures only have the lifetime of the ARMCPU struct. We create and destroy these at
runtime, so at some point you may end up with pointers to freed memory.
r~
