64-bit Arm architecture

Modifying the purge configurations such as "innodb_purge_threads" and/or having more number of CPU cores indeed makes the purge faster.

Having said that, the main concern is the performance difference between "x86_64" and "arm64" machines.
With exact same engine configuration and workload, the purge operation takes a lot of time to complete on "arm64"

In the above(sysbench) test :
== purge took ~15 minutes to complete after the sysbench test completed : on "arm64"
== purge completed within a minute after the sysbench test completed : on "x86_64"

1. Issue is that purge is slow is on ARM (when compared to x86).

2. So I tried running an extended workload to help trace how the history length continues to reduce over a period of time.

<NOTE: My ARM and x86 VM are not comparable so don't compare the tps directly but they have same number of cores and same kind of Cloud Disk>

Check the graph attached. I see ARM continue to purge as quickly as x86.

I don't have a that small VM so I have used VM with 24 cores out of which 20 cores are allotted to server and 4 for sysbench workload.
Also, if you need to check the exact configuration you can find it here. https://github.com/mysqlonarm/benchmark-suites/blob/master/mysql-sbench/conf/mdb.cnf/100tx3m_106_cpubound.cnf
server-version: 10.6.5

Quick note about workload: 5 round of 300 sec each with 20 sec gap after each round and then just continue to monitor stats (like history-length, etc..) for another 100 secs.

I am not sure why someone would like to measure history length during the loading of the data (given it hardly grow the significant level) but assuming there is use-case I tried to measure the same too as suggested in the original text.
Again, ARM was able to load the data faster than x86 and also was a forerunner in fading out history length. check the attached graph.

Thank you for checking this, krunalbauskar.

The difference could very well be due to something else than the instruction set architecture or its implementation in a CPU core. If the ARM system has only 2 ARMv8 cores, then I would think that it should be compared to a similar AMD64 implementation. I see that all Intel Atom products that were launched in 2021 feature 2 or 4 cores. A dual-core Atom might be more comparable to a 2-core ARMv8 system. Also the I/O and memory bus architecture could play a significant role.

When it comes to sysbench prepare, it could be sped up in MariaDB 10.6 and later by applying a change like this to enable the use of bulk insert. In 10.6, that will disable row-level undo logging when inserting into an empty table. MDEV-24621 in 10.7 improved the index tree creation too. Unfortunately, due to current limitations of the storage engine interface, MDEV-24621 only applies to the first statement that inserts into an empty table or partition.