All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chen, Yu C" <yu.c.chen@intel.com>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	David Vernet <void@manifault.com>,
	"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
	"Swapnil Sapkal" <swapnil.sapkal@amd.com>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Juri Lelli" <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	<linux-kernel@vger.kernel.org>, <yu.c.chen@intel.com>,
	<yu.chen.surf@foxmail.com>
Subject: Re: [RFC PATCH 6/8] sched/fair: Increase probability of lb stats being reused
Date: Tue, 18 Mar 2025 02:07:40 +0800	[thread overview]
Message-ID: <8d4edcf9-bcf6-4832-8840-dd8aed1639a1@intel.com> (raw)
In-Reply-To: <20250313093746.6760-7-kprateek.nayak@amd.com>

On 3/13/2025 5:37 PM, K Prateek Nayak wrote:
> The load balancer will start caching the sg_lb_stats during load
> balancing and propagate it up the sched domain hierarchy in the
> subsequent commits.
> 
> Increase the probability of load balancing intervals across domains to
> be aligned to improve the reuse efficiency of the propagated stats.
> Go one step further and proactively explore balancing at a higher domain
> if the next update time for a higher domain in before the next update
> time for its children.
> 
> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
> ---
>   kernel/sched/fair.c | 18 +++++++-----------
>   1 file changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 3b1ed14e4b5e..60517a732c10 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -11956,15 +11956,6 @@ get_sd_balance_interval(struct sched_domain *sd, int cpu_busy)
>   
>   	/* scale ms to jiffies */
>   	interval = msecs_to_jiffies(interval);
> -
> -	/*
> -	 * Reduce likelihood of busy balancing at higher domains racing with
> -	 * balancing at lower domains by preventing their balancing periods
> -	 * from being multiples of each other.
> -	 */
> -	if (cpu_busy)
> -		interval -= 1;
> -
>   	interval = clamp(interval, 1UL, max_load_balance_interval);
>   
>   	return interval;
> @@ -12126,7 +12117,7 @@ static void sched_balance_domains(struct rq *rq, enum cpu_idle_type idle)
>   	int continue_balancing = 1;
>   	int cpu = rq->cpu;
>   	int busy = idle != CPU_IDLE && !sched_idle_cpu(cpu);
> -	unsigned long interval;
> +	unsigned long interval, prev_sd_next_balance = 0;
>   	struct sched_domain *sd;
>   	/* Earliest time when we have to do rebalance again */
>   	unsigned long next_balance = jiffies + 60*HZ;
> @@ -12136,6 +12127,8 @@ static void sched_balance_domains(struct rq *rq, enum cpu_idle_type idle)
>   
>   	rcu_read_lock();
>   	for_each_domain(cpu, sd) {
> +		unsigned long next_interval;
> +
>   		/*
>   		 * Decay the newidle max times here because this is a regular
>   		 * visit to all the domains.
> @@ -12162,7 +12155,9 @@ static void sched_balance_domains(struct rq *rq, enum cpu_idle_type idle)
>   				goto out;
>   		}
>   
> -		if (time_after_eq(jiffies, sd->last_balance + interval)) {
> +		next_interval = sd->last_balance + interval;
> +		if (time_after_eq(jiffies, next_interval) ||
> +		    (prev_sd_next_balance && time_after(prev_sd_next_balance, next_interval))) {

(prev_sd_next_balance && time_after(jiffies, prev_sd_next_balance))?

thanks,
Chenyu

>   			if (sched_balance_rq(cpu, rq, sd, idle, &continue_balancing)) {
>   				/*
>   				 * The LBF_DST_PINNED logic could have changed
> @@ -12174,6 +12169,7 @@ static void sched_balance_domains(struct rq *rq, enum cpu_idle_type idle)
>   			}
>   			sd->last_balance = jiffies;
>   			interval = get_sd_balance_interval(sd, busy);
> +			prev_sd_next_balance = sd->last_balance + interval;
>   		}
>   		if (need_serialize)
>   			atomic_set_release(&sched_balance_running, 0);

  reply	other threads:[~2025-03-17 18:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13  9:37 [RFC PATCH 0/8] sched/fair: Propagate load balancing stats up the sched domain hierarchy K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 1/8] sched/topology: Assign sd_share for all non NUMA sched domains K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 2/8] sched/topology: Introduce sg->shared K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 3/8] sched/fair: Move "struct sg_lb_stats" and its dependencies to sched.h K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 4/8] sched/fair: Move sg_{overloaded,overutilized} calculation to sg_lb_stats K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 5/8] sched/topology: Define sg_lb_stats_prop and embed it inside sched_domain_shared K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 6/8] sched/fair: Increase probability of lb stats being reused K Prateek Nayak
2025-03-17 18:07   ` Chen, Yu C [this message]
2025-03-19  6:51     ` K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 7/8] sched/fair: Retrieve cached group stats from sg_lb_stats_prop K Prateek Nayak
2025-03-17 18:04   ` Chen, Yu C
2025-03-19  6:42     ` K Prateek Nayak
2025-03-13  9:37 ` [RFC PATCH 8/8] sched/fair: Update stats for sched_domain using the sched_group stats K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 09/08] [ANNOTATE] sched/fair: Stats versioning and invalidation K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 10/08] sched/fair: Compute nr_{numa,preferred}_running for non-NUMA domains K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 11/08] sched/fair: Move from "last_update" to stats versioning K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 12/08] sched/fair: Record the cpu that updated the stats last K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 13/08] sched/fair: Invalidate stats once the load balancing instance is done K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 14/08] [DEBUG] sched/fair: Add more lb_stats around lb_time and stats reuse K Prateek Nayak
2025-03-16 10:29 ` [RFC PATCH 15/08] [DEBUG] tools/lib/perf: Extend schedstats v17 headers to include the new debug fields K Prateek Nayak
2025-03-17 17:25 ` [RFC PATCH 0/8] sched/fair: Propagate load balancing stats up the sched domain hierarchy Peter Zijlstra
2025-03-17 18:23   ` Chen, Yu C
2025-03-21 10:04 ` Libo Chen
2025-03-24  3:58   ` K Prateek Nayak

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=8d4edcf9-bcf6-4832-8840-dd8aed1639a1@intel.com \
    --to=yu.c.chen@intel.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gautham.shenoy@amd.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=swapnil.sapkal@amd.com \
    --cc=vincent.guittot@linaro.org \
    --cc=void@manifault.com \
    --cc=vschneid@redhat.com \
    --cc=yu.chen.surf@foxmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.