we discussed this in a core-team meeting and we weren't sure if we want it, and how useful it is.
considering we do have the activerehashing config, one can argue that this information is useful to take actions, but on the other hand, there are other info fields that indicate there's a rehashing in progress, and we're not sure knowing the amount of CPU utilized is really helpful.

we didn't want to spam the info fields (although this is a mirror of expire_cycle_cpu_milliseconds)
we decided to hold this aside until someone comes with good indication that it's really needed and how it'll be used.

another point i want to mention is that currently we will spend a fixed 1000us in each serverCron to do activerehash. The text describe it in redis.conf is:

The default is to use this millisecond 10 times every second in order to actively rehash the main dictionaries, freeing memory when possible.

however, this is when hz = 10. Sometimes users set hz randomly, causing the load to become higher. although we now have some new indicators, it doesn’t seem to be clear (we did not mention it in the redis.conf, it look like we should). or i previously suggested changing 1000us to something like active expire or defrag based on hz calculation.

but on the other hand, there are other info fields that indicate there's a rehashing in progress, and we're not sure knowing the amount of CPU utilized is really helpful.

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}