Db2 TOTAL_CPU_TIME monitoring metric on AIX should reflect "wall" CPU time and not use PURR-scaled time reported currently by thread_cputime AIX API

Db2 monitoring interfaces report "CPU time" metric (TOTAL_CPU_TIME), which accounts the time that given activity/request (and all higher level aggregated interfaces) spent actively "on CPU" whilst executing the query.


On AIX this information is obtained using APIs:

·        getrusage64 (currently)
·        thread_cputime (in the future fix packs) 

Both of those return time scaled with Processor Utilization Resource register (PURR) value, which makes the value lower than the "wall time" for which given thread was active on the CPU, some background about the behaviour is documented on IBM Community blog entry:
https://community.ibm.com/community/user/power/blogs/kamalesh-babulal/2021/07/09/rethinking-cpu-utilization-with-purrspurr

 Db2 documentation reports that TOTAL_CPU_TIME is actual user + system CPU time in microseconds:

The total amount of CPU time used while within the database system. Represents total of both user and system CPU time. This value is in microseconds.

Because of the PURR scaling the value is always undercounted for any SMT modes higher than 1 on AIX. As the result, analysis of the time spent metrics (how much wait vs CPU time contribute to TOTAL_ACT_TIME) cannot be precise and might be misleading for user during troubleshooting and bottleneck analysis.
Db2 should use API that reports wall clock (possibly pm_get_data_mythread) or request IBM AIX team for an optional flag for current thread_cputime that would report non-scaled time (accu_timebase in pm_get_data_mythread)