All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <yu.c.chen@intel.com>
To: Shrikanth Hegde <sshegde@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	"Tim Chen" <tim.c.chen@intel.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
	Chen Yu <yu.chen.surf@gmail.com>, Aaron Lu <aaron.lu@intel.com>,
	<linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [RFC PATCH 5/7] sched/fair: Adjust the busiest group scanning depth in idle load balance
Date: Wed, 30 Aug 2023 23:35:09 +0800	[thread overview]
Message-ID: <ZO9hrc2KDUOfbQm1@chenyu5-mobl2> (raw)
In-Reply-To: <cca85edb-0c16-05d1-a734-5148054ba7a7@linux.vnet.ibm.com>

On 2023-08-25 at 11:30:05 +0530, Shrikanth Hegde wrote:
> 
> 
> On 7/27/23 8:05 PM, Chen Yu wrote:
> > Scanning the whole sched domain to find the busiest group is time costly
> > during newidle_balance(). And if a CPU becomes idle, it would be good
> > if this idle CPU pulls some tasks from other CPUs as quickly as possible.
> > 
> > Limit the scan depth of newidle_balance() to only scan for a limited number
> > of sched groups to find a relatively busy group, and pull from it.
> > In summary, the more spare time there is in the domain, the more time
> > each newidle balance can spend on scanning for a busy group. Although
> > the newidle balance has per domain max_newidle_lb_cost to decide
> > whether to launch the balance or not, the ILB_UTIL provides a smaller
> > granularity to decide how many groups each newidle balance can scan.
> > 
> > The scanning depth is calculated by the previous periodic load balance
> > based on its overall utilization.
> > 
> > Tested on top of v6.5-rc2, Sapphire Rapids with 2 x 56C/112T = 224 CPUs.
> > With cpufreq governor set to performance, and C6 disabled.
> > 
> > Firstly, tested on a extreme synthetic test[1], which launches 224
> > process. Each process is a loop of nanosleep(1 us), which is supposed
> > to trigger newidle balance as much as possible:
> > 
> > i=1;while [ $i -le "224" ]; do ./nano_sleep 1000 & i=$(($i+1)); done;
> > 
> > NO_ILB_UTIL + ILB_SNAPSHOT:
> > 9.38%     0.45%  [kernel.kallsyms]   [k] newidle_balance
> > 6.84%     5.32%  [kernel.kallsyms]   [k] update_sd_lb_stats.constprop.0
> > 
> > ILB_UTIL + ILB_SNAPSHOT:
> > 3.35%     0.38%  [kernel.kallsyms]   [k] newidle_balance
> > 2.30%     1.81%  [kernel.kallsyms]   [k] update_sd_lb_stats.constprop.0
> > [...]
> 
> > Link: https://raw.githubusercontent.com/chen-yu-surf/tools/master/stress_nanosleep.c #1
> > Suggested-by: Tim Chen <tim.c.chen@intel.com>
> > Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> > ---
> >  kernel/sched/fair.c | 20 +++++++++++++++++++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 6925813db59b..4e360ed16e14 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -10195,7 +10195,13 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
> >  	struct sg_lb_stats *local = &sds->local_stat;
> >  	struct sg_lb_stats tmp_sgs;
> >  	unsigned long sum_util = 0;
> > -	int sg_status = 0;
> > +	int sg_status = 0, nr_sg_scan;
> > +	/* only newidle CPU can load the snapshot */
> > +	bool ilb_can_load = env->idle == CPU_NEWLY_IDLE &&
> > +			    sd_share && READ_ONCE(sd_share->total_capacity);
> > +
> > +	if (sched_feat(ILB_UTIL) && ilb_can_load)
> 
> Suggestion for small improvement:
> 
> it could be ? This could help save a few cycles of checking if the feature is enabled when its not newidle. 
> 
> 	if ( ilb_can_load && sched_feat(ILB_UTIL)) 
> 
> Same comments below in this patch as well in PATCH 6/7.
>

Yes this makes sense because the feature is enabled by default.
 
> > +		nr_sg_scan = sd_share->nr_sg_scan;
> >  
> >  	do {
> >  		struct sg_lb_stats *sgs = &tmp_sgs;
> > @@ -10222,6 +10228,9 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
> >  			sds->busiest_stat = *sgs;
> >  		}
> >  
> > +		if (sched_feat(ILB_UTIL) && ilb_can_load && --nr_sg_scan <= 0)
> > +			goto load_snapshot;
> > +
> 
> Same comment as above.
> 

OK, will do.

thanks,
Chenyu

  reply	other threads:[~2023-08-30 19:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27 14:33 [RFC PATCH 0/7] Optimization to reduce the cost of newidle balance Chen Yu
2023-07-27 14:34 ` [RFC PATCH 1/7] sched/topology: Assign sd_share for all non NUMA sched domains Chen Yu
2023-07-27 14:34 ` [RFC PATCH 2/7] sched/topology: Introduce nr_groups in sched_domain to indicate the number of groups Chen Yu
2023-07-27 14:34 ` [RFC PATCH 3/7] sched/fair: Save a snapshot of sched domain total_load and total_capacity Chen Yu
2023-07-27 14:35 ` [RFC PATCH 4/7] sched/fair: Calculate the scan depth for idle balance based on system utilization Chen Yu
2023-08-25  6:02   ` Shrikanth Hegde
2023-08-30 15:30     ` Chen Yu
2023-07-27 14:35 ` [RFC PATCH 5/7] sched/fair: Adjust the busiest group scanning depth in idle load balance Chen Yu
2023-08-25  6:00   ` Shrikanth Hegde
2023-08-30 15:35     ` Chen Yu [this message]
2023-07-27 14:35 ` [RFC PATCH 6/7] sched/fair: Pull from a relatively busy group during newidle balance Chen Yu
2023-07-27 14:35 ` [RFC PATCH 7/7] sched/stats: Track the scan number of groups during load balance Chen Yu
2023-08-25  7:48 ` [RFC PATCH 0/7] Optimization to reduce the cost of newidle balance Shrikanth Hegde
2023-08-30 15:26   ` Chen Yu
2023-09-10  7:51     ` Shrikanth Hegde
2024-07-16 14:16 ` Matt Fleming
2024-07-17  3:52   ` Chen Yu
2024-07-17 15:31     ` Matt Fleming
2024-07-17 12:17 ` Peter Zijlstra
2024-07-18  9:28   ` K Prateek Nayak
2024-07-18 17:01     ` Chen Yu
2024-07-18 16:57   ` Chen Yu

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=ZO9hrc2KDUOfbQm1@chenyu5-mobl2 \
    --to=yu.c.chen@intel.com \
    --cc=aaron.lu@intel.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@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sshegde@linux.vnet.ibm.com \
    --cc=tim.c.chen@intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=yu.chen.surf@gmail.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.