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: Wed, 28 Aug 2024 08:43:55 -0700 (PDT)	[thread overview]
Message-ID: <8dcf25e3-1acd-f629-cea0-bfeebf06e7a5@gentwo.org> (raw)
In-Reply-To: <20240828053737.GA22322@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>

On Tue, 27 Aug 2024, Saurabh Singh Sengar wrote:

> 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.

Good.

There was the question by Andrew as to what happens if the
threshold is not initialized. I have no specific benchmarks to measure the
effect.

> > 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);

The thresholds vary per the zone setup in a NUMA node. So one approach
would be to calculate  these values for each new NODE once and only
update them when memory is brought online or offlines.

Then the parameters for each per cpu pcp could be set from the per NODE /
zone information when a cpu is brought up. The overhead would be minimal
and there would not be a need for the loops.

My company has similar amounts of cpus and it would be great to have a
clean solution here.



  reply	other threads:[~2024-08-28 15:44 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)
2024-08-28  5:37       ` Saurabh Singh Sengar
2024-08-28 15:43         ` Christoph Lameter (Ampere) [this message]
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=8dcf25e3-1acd-f629-cea0-bfeebf06e7a5@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