On Sat, Aug 10, 2024 at 12:04:04AM -0700, Andrew Morton wrote: > On Mon, 8 Jul 2024 21:57:50 -0700 Saurabh Singh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > No NUMA = 1024*2*1*512 = 1,048,576 : Here refresh_zone_stat_thresholds > > > > takes around 224 ms total for all the CPUs in the system under test. > > > > 16 NUMA = 1024*2*16*512 = 16,777,216 : Here refresh_zone_stat_thresholds > > > > takes around 4.5 seconds total for all the CPUs in the system under test. > > > > > > Did you measure the overall before-and-after times? IOW, how much of > > > that 4.5s do we reclaim? > > > > This entire gain is accounted in over all boot processi time. Most of the Linux > > kernel boot process is sequential and doesn't take advantage of SMP. > > Again, if you were able to measure 4.5s without the patch then you are > able to measure how long this delay is with the patch. Please share > that number. If I understand your question correctly, you're asking about the total time taken by refresh_zone_stat_threshold for all its executions before and after the fix. Without this patch, refresh_zone_stat_threshold was being called 1024 times. After applying the patch, it is called only once, which is same as the last iteration of the earlier 1024 calls. Further testing with this patch, I observed a 4.5-second improvement in the overall boot timing due to this fix, which is same as the total time taken by refresh_zone_stat_thresholds without thie patch, leading me to reasonably conclude that refresh_zone_stat_threshold now takes a negligible amount of time (likely just a few milliseconds). If you would like precise timing details on single refresh_zone_stat_threshold execution, please let me know, and I can conduct the tests again and provide the results in few days. - Saurabh
