linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Saurabh Singh Sengar <ssengar@linux.microsoft.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	ssengar@microsoft.com, wei.liu@kernel.org
Subject: Re: [PATCH] mm/vmstat: Defer the refresh_zone_stat_thresholds after all CPUs bringup
Date: Fri, 23 Aug 2024 08:32:43 -0700 (PDT)	[thread overview]
Message-ID: <5a18105c-8e6f-39fa-370f-2d839d9ab843@gentwo.org> (raw)
In-Reply-To: <20240709045750.GA32083@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>

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.

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.



  parent reply	other threads:[~2024-08-23 15:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-05  8:48 Saurabh Sengar
2024-07-05 20:59 ` Andrew Morton
2024-07-09  4:57   ` Saurabh Singh Sengar
2024-07-09 21:45     ` Andrew Morton
2024-08-10  7:04     ` Andrew Morton
2024-08-12  4:37       ` Saurabh Singh Sengar
2024-08-13 23:37         ` Andrew Morton
2024-08-23 15:32     ` Christoph Lameter (Ampere) [this message]
2024-08-28  5:37       ` Saurabh Singh Sengar
2024-08-28 15:43         ` Christoph Lameter (Ampere)
2024-08-09  5:20 ` Andrew Morton
2024-08-09  5:49   ` Saurabh Singh Sengar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a18105c-8e6f-39fa-370f-2d839d9ab843@gentwo.org \
    --to=cl@gentwo.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ssengar@linux.microsoft.com \
    --cc=ssengar@microsoft.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox