On Fri, Aug 23, 2024 at 08:32:43AM -0700, Christoph Lameter (Ampere) wrote: > On Mon, 8 Jul 2024, Saurabh Singh Sengar wrote: > > > > > Calling this for each CPU is expensive when there are large number > > > > of CPUs along with multiple NUMAs. Fix this by deferring > > > > refresh_zone_stat_thresholds to be called later at once when all the > > > > secondary CPUs are up. Also, register the DYN hooks to keep the > > > > existing hotplug functionality intact. > > > > > > > > > > Seems risky - we'll now have online CPUs which have unintialized data, > > > yes? What assurance do we have that this data won't be accessed? > > > > I understand that this data is only accessed by userspace tools, and they can > > only access it post late_initcall. Please let me know if there are any other > > cases, I will look to address them. > > stat_threshold is used in all statistics functions that modify VM > counters. It is core to the functioning of the VM statistics. > > However, if the threshold is zero (not initialized) then the VM counter > handling will simply be less effective because it will not do the per cpu > counter diffs anymore. This may increase contention and eat up the benefit > you are getting from deferring the calculation of the threshholds. Christoph, Thank you for your review. I would like to gain a better understanding of how to measure contention. Could you please inform me if there is any recommended method for doing so? In my testing, this patch has resulted in a significant improvement in boot time. > > What may be more promising is to make it possible to calculate the > threshholds per cpu instead of recalculating the thresholds for every zone > again and again. I am happy to explore alternatives, can you please share more details around this approach. Are you referring to avoiding the repetition of the calculation below? mem = zone_managed_pages(zone) >> (27 - PAGE_SHIFT); - Saurabh
