mirror of https://lore.kernel.org/lkml/
 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 0/7] Optimization to reduce the cost of newidle balance
Date: Wed, 30 Aug 2023 23:26:54 +0800	[thread overview]
Message-ID: <ZO9fvgovn/MtLVzZ@chenyu5-mobl2> (raw)
In-Reply-To: <8561f192-ccd0-c2e3-3115-8cf09a7d3e55@linux.vnet.ibm.com>

Hi Shrikanth,

On 2023-08-25 at 13:18:56 +0530, Shrikanth Hegde wrote:
> 
> On 7/27/23 8:03 PM, Chen Yu wrote:
> 
> Hi Chen. It is a nice patch series in effort to reduce the newidle cost. 
> This gives the idea of making use of calculations done in load_balance to used 
> among different idle types. 
>

Thanks for taking a look at this patch set.
 
> It was interesting to see how this would work on Power Systems. The reason being we have 
> large core count and LLC size is small. i.e at small core level (llc_weight=4). This would
> mean quite frequest access sd_share at different level which would reside on the first_cpu of 
> the sched domain, which might result in more cache-misses. But perf stats didnt show the same.
>

Do you mean 1 large domain(Die domain?) has many LLC sched domains as its children,
and accessing the large domain's sd_share field would cross different LLCs and the
latency is high? Yes, this could be a problem and it depends on the hardware that how
fast differet LLCs snoop the data with each other.
On the other hand, the periodic load balance is the writer of sd_share, and the
interval is based on the cpu_weight of that domain. So the write might be less frequent
on large domains, and most access to sd_share would be the read issued by newidle balance,
which is less costly.
 
> Another concern on more number of sched  groups at DIE level, which might take a hit if 
> the balancing takes longer for the system to stabilize. 

Do you mean, if newidle balance does not pull tasks hard enough, the imbalance between groups
would last longer? Yes, Prateek has mentioned this point, the ILB_UTIL has this problem, I'll
think more about it. We want to find a way in newidle balance to do less scan, but still pulls
tasks as hard as before.

> 
> tl;dr
> 
> Tested with micro-benchmarks on system with 96 Cores with SMT=8. Total of 768 CPU's. There is some amount 

May I know the sched domain hierarchy of this platform?
grep . /sys/kernel/debug/sched/domains/cpu0/domain*/*
cat /proc/schedstat  | grep cpu0 -A 4  (4 domains?)

> of regression with hackbench and schbench. haven't looked into why. Any pointers to check would be helpful.

May I know what is the command to run hackbench and schbench below? For example
the fd number, package size and the loop number of hackbench, and
number of message thread and worker thread of schbench, etc. I assume
you are using the old schbench? As the latest schbench would track other metrics
besides tail latency.


> Did a test with more real case workload that we have called daytrader. Its is DB workload which gives total
> transcations done per second. That doesn't show any regression.
> 
> Its true that all benchmarks will not be happy.
> Maybe in below cases, newidle may not be that costly. Do you have any specific benchmark to be tried? 
> 

Previously I tested schbench/hackbench/netperf/tbench/sqlite, and also I'm planning
to try an OLTP.

> -----------------------------------------------------------------------------------------------------
> 					6.5.rc4			6.5.rc4 + PATCH_V2 		gain					
> Daytrader:				55049				55378			0.59%
> 
> -----------------------------------------------------------------------------------------------------
> hackbench(50 iterations):			   6.5.rc4	6.5.rc4 + PATCH_V2(gain%)
> 
> 
> Process 10 groups                    :       0.19,       0.19(0.00)             
> Process 20 groups                    :       0.23,       0.24(-4.35)            
> Process 30 groups                    :       0.28,       0.30(-7.14)            
> Process 40 groups                    :       0.38,       0.40(-5.26)            
> Process 50 groups                    :       0.43,       0.45(-4.65)            
> Process 60 groups                    :       0.51,       0.51(0.00)             
> thread 10 Time                       :       0.21,       0.22(-4.76)            
> thread 20 Time                       :       0.27,       0.32(-18.52)           
> Process(Pipe) 10 Time                :       0.17,       0.17(0.00)             
> Process(Pipe) 20 Time                :       0.23,       0.23(0.00)             
> Process(Pipe) 30 Time                :       0.28,       0.28(0.00)             
> Process(Pipe) 40 Time                :       0.33,       0.32(3.03)             
> Process(Pipe) 50 Time                :       0.38,       0.36(5.26)             
> Process(Pipe) 60 Time                :       0.40,       0.39(2.50)             
> thread(Pipe) 10 Time                 :       0.14,       0.14(0.00)             
> thread(Pipe) 20 Time                 :       0.20,       0.19(5.00) 
> 
> Observation: lower is better. socket based runs show regression quite a bit, 
> pipe shows slight improvement. 
> 
> 
> -----------------------------------------------------------------------------------------------------
> Unixbench(10 iterations):			   6.5.rc4	6.5.rc4 + PATCH_V2(gain%)
> 
> 1 X Execl Throughput                  :    4280.15,    4398.30(2.76)           
> 4 X Execl Throughput                  :    8171.60,    8061.60(-1.35)            
> 1 X Pipe-based Context Switching      :  172455.50,  174586.60(1.24)           
> 4 X Pipe-based Context Switching      :  633708.35,  664659.85(4.88)           
> 1 X Process Creation                  :    6891.20,    7056.85(2.40)           
> 4 X Process Creation                  :    8826.20,    8996.25(1.93)           
> 1 X Shell Scripts (1 concurrent)      :    9272.05,    9456.10(1.98)           
> 4 X Shell Scripts (1 concurrent)      :   27919.60,   25319.75(-9.31)            
> 1 X Shell Scripts (8 concurrent)      :    4462.70,    4392.75(-1.57)            
> 4 X Shell Scripts (8 concurrent)      :   11852.30,   10820.70(-8.70) 
> 
> Observation: higher is better. Results are somewhat mixed.  
> 
> 
> -----------------------------------------------------------------------------------------------------
> schbench(10 iterations)			 6.5.rc4	6.5.rc4 + PATCH_V2(gain%)
> 
> 1 Threads                                                                       
> 50.0th:                                   8.00,       7.00(12.50)               
> 75.0th:                                   8.00,       7.60(5.00)                
> 90.0th:                                   8.80,       8.00(9.09)                
> 95.0th:                                  10.20,       8.20(19.61)               
> 99.0th:                                  13.60,      11.00(19.12)               
> 99.5th:                                  14.00,      12.80(8.57)                
> 99.9th:                                  15.80,      35.00(-121.52)             
> 2 Threads                                                                       
> 50.0th:                                   8.40,       8.20(2.38)                
> 75.0th:                                   9.00,       8.60(4.44)                
> 90.0th:                                  10.20,       9.60(5.88)                
> 95.0th:                                  11.20,      10.20(8.93)                
> 99.0th:                                  14.40,      11.40(20.83)               
> 99.5th:                                  14.80,      12.80(13.51)               
> 99.9th:                                  17.60,      14.80(15.91)               
> 4 Threads                                                                       
> 50.0th:                                  10.60,      10.40(1.89)                
> 75.0th:                                  12.20,      11.60(4.92)                
> 90.0th:                                  13.60,      12.60(7.35)                
> 95.0th:                                  14.40,      13.00(9.72)                
> 99.0th:                                  16.40,      15.60(4.88)                
> 99.5th:                                  16.80,      16.60(1.19)                
> 99.9th:                                  22.00,      29.00(-31.82)              
> 8 Threads                                                                       
> 50.0th:                                  12.00,      11.80(1.67)                
> 75.0th:                                  14.40,      14.40(0.00)                
> 90.0th:                                  17.00,      18.00(-5.88)               
> 95.0th:                                  19.20,      19.80(-3.13)               
> 99.0th:                                  23.00,      24.20(-5.22)               
> 99.5th:                                  26.80,      29.20(-8.96)               
> 99.9th:                                  68.00,      97.20(-42.94)  
> 16 Threads                                                                      
> 50.0th:                                  18.00,      18.20(-1.11)               
> 75.0th:                                  23.20,      23.60(-1.72)               
> 90.0th:                                  28.00,      27.40(2.14)                
> 95.0th:                                  31.20,      30.40(2.56)                
> 99.0th:                                  38.60,      38.20(1.04)                
> 99.5th:                                  50.60,      50.40(0.40)                
> 99.9th:                                 122.80,     108.00(12.05)               
> 32 Threads                                                                      
> 50.0th:                                  30.00,      30.20(-0.67)               
> 75.0th:                                  42.20,      42.60(-0.95)               
> 90.0th:                                  52.60,      55.40(-5.32)               
> 95.0th:                                  58.60,      63.00(-7.51)               
> 99.0th:                                  69.60,      78.20(-12.36)              
> 99.5th:                                  79.20,     103.80(-31.06)              
> 99.9th:                                 171.80,     209.60(-22.00)
> 
> Observation: lower is better. tail latencies seem to go up. schbench also has run to run variations.
> 
> -----------------------------------------------------------------------------------------------------
> stress-ng(20 iterations)	   6.5.rc4	6.5.rc4 + PATCH_V2(gain%)
> 	 ( 100000 cpu-ops)
> 
> --cpu=768 Time               :       1.58,       1.53(3.16)                     
> --cpu=384 Time               :       1.66,       1.63(1.81)                     
> --cpu=192 Time               :       2.67,       2.77(-3.75)                    
> --cpu=96 Time                :       3.70,       3.69(0.27)                     
> --cpu=48 Time                :       5.73,       5.69(0.70)                     
> --cpu=24 Time                :       7.27,       7.26(0.14)                     
> --cpu=12 Time                :      14.25,      14.24(0.07)                     
> --cpu=6 Time                 :       28.42,      28.40(0.07)                    
> --cpu=3 Time                 :      56.81,      56.68(0.23)                     
> --cpu=768 -util=10 Time      :       3.69,       3.70(-0.27)                    
> --cpu=768 -util=20 Time      :       5.67,       5.70(-0.53)                    
> --cpu=768 -util=30 Time      :       7.08,       7.12(-0.56)                    
> --cpu=768 -util=40 Time      :       8.23,       8.27(-0.49)                    
> --cpu=768 -util=50 Time      :       9.22,       9.26(-0.43)                    
> --cpu=768 -util=60 Time      :      10.09,      10.15(-0.59)                    
> --cpu=768 -util=70 Time      :      10.93,      10.98(-0.46)                    
> --cpu=768 -util=80 Time      :      11.79,      11.79(0.00)                     
> --cpu=768 -util=90 Time      :      12.63,      12.60(0.24) 
> 
> 
> Observation: lower is better. Almost no difference.

I'll try to run the same tests of hackbench/schbench on my machine, to
see if I could find any clue for the regression.


thanks,
Chenyu

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

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27 14:33 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
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 [this message]
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=ZO9fvgovn/MtLVzZ@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®