diff mbox

[sched] 73628fba4: +69% context switches

Message ID 52D3804A.8060700@linaro.org
State New
Headers show

Commit Message

Alex Shi Jan. 13, 2014, 5:57 a.m. UTC
On 01/11/2014 06:19 PM, Fengguang Wu wrote:
> Alex,
> 
> FYI, we find much increased interrupts and context switches introduced
> by commit 73628fba4 ("sched: unify imbalance bias for target group")
> in your noload branch:

Many thanks for the generous and quick testing! :)

few questions for the results and give a testing patch for try. it also push on github. 

What's about the aim7 shell_rtns_1 and shared throughput?
> 
> 7bea8c18805a5f1  73628fba451ae72221b155696  
> ---------------  -------------------------  
>      14979 ~ 4%   +1304.8%     210434 ~ 1%  lkp-ne04/micro/aim7/shell_rtns_1
>       2748 ~ 5%    +977.4%      29607 ~ 0%  nhm-white/micro/aim7/shared
>      17727        +1254.1%     240041       TOTAL interrupts.RES

RES interrupt increased about 200,000, but vmstat's interrupt increased a little. guess the vmstat data is per seconds, right? If so, it is better give how long time the vmstat running.

The same problem on the time.involuntary_context_switches and vmstat cs.

According to involuntary CS definition in time, RES interrupt will cause involuntary CS. but here 29607 RES of aim7/shared cause 233218 time inv CS, does sth I missed or the data is incorrect?

> 
> 7bea8c18805a5f1  73628fba451ae72221b155696  
> ---------------  -------------------------  
>       3617 ~ 0%     +69.2%       6118 ~ 0%  lkp-ne04/micro/aim7/shell_rtns_1
>       3617          +69.2%       6118       TOTAL vmstat.system.in
> 
> 7bea8c18805a5f1  73628fba451ae72221b155696  
> ---------------  -------------------------  
>     132746 ~ 0%     +69.0%     224346 ~ 1%  lkp-ne04/micro/aim7/shell_rtns_1
>     220038 ~ 0%      +6.0%     233218 ~ 0%  nhm-white/micro/aim7/shared
>     352785          +29.7%     457564       TOTAL time.involuntary_context_switches
> 
> 7bea8c18805a5f1  73628fba451ae72221b155696  
> ---------------  -------------------------  
>    1424581 ~ 0%      +8.6%    1546786 ~ 0%  lkp-ne04/micro/aim7/shell_rtns_1
>    1424581           +8.6%    1546786       TOTAL time.voluntary_context_switches
> 
> 7bea8c18805a5f1  73628fba451ae72221b155696  
> ---------------  -------------------------  
>      20982 ~ 0%     +12.5%      23599 ~ 0%  lkp-ne04/micro/aim7/shell_rtns_1
>       6005 ~ 0%      +4.2%       6256 ~ 0%  nhm-white/micro/aim7/shared
>      26988          +10.6%      29856       TOTAL vmstat.system.cs
> 
>                                   vmstat.system.cs
> 

commit c5a8778a132cfa882609fbccb4ee6542eac9866d
Author: Alex Shi <alex.shi@linaro.org>
Date:   Mon Jan 13 13:54:30 2014 +0800

    more bias towards local cpu group

Comments

Alex Shi Jan. 16, 2014, 2:02 a.m. UTC | #1
On 01/16/2014 09:23 AM, Fengguang Wu wrote:
> On Mon, Jan 13, 2014 at 01:57:30PM +0800, Alex Shi wrote:
>> On 01/11/2014 06:19 PM, Fengguang Wu wrote:
>>> Alex,
>>>
>>> FYI, we find much increased interrupts and context switches introduced
>>> by commit 73628fba4 ("sched: unify imbalance bias for target group")
>>> in your noload branch:
>>
>> Many thanks for the generous and quick testing! :)
>>
>> few questions for the results and give a testing patch for try. it also push on github. 
>>
>> What's about the aim7 shell_rtns_1 and shared throughput?
> 
> The throughputs remain the same.  We only report changed numbers.

So many interrupt increase doesn't cause any performance change, that
make more doubt of data correction.
Could you like to give the typical vmstat output? Specially the
sys/us/wa/id time percentages.

BTW
Just confirm, the benchmark is running on a native machine, not a kvm
guest, right?

>>
>> commit c5a8778a132cfa882609fbccb4ee6542eac9866d
>> Author: Alex Shi <alex.shi@linaro.org>
>> Date:   Mon Jan 13 13:54:30 2014 +0800
>>
>>     more bias towards local cpu group
> 
> 
> In your rebased tree, there are still much increased interrupts and
> context switches:
> 

Thanks for your great testing!
Seems I tune it to the wrong direction. :)

Will change to another directory to reduce the questionable interrupt/CS
increase.
Alex Shi Jan. 16, 2014, 2:46 a.m. UTC | #2
>>>> > >>
>>>> > >> What's about the aim7 shell_rtns_1 and shared throughput?
>>> > > 
>>> > > The throughputs remain the same.  We only report changed numbers.
>> > 
>> > So many interrupt increase doesn't cause any performance change, that
>> > make more doubt of data correction.
>> > Could you like to give the typical vmstat output? Specially the
>> > sys/us/wa/id time percentages.

> wfg@bee /lkp/result/lkp-ne04/micro/aim7/shell_rtns_1/x86_64-lkp/91dd08bd65052b483f96f75abcc93f2f1b67a62c/1% cat vmstat
> 1389799131.230965 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
> 1389799131.231067  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
> 1389799143.207206 1912 26      0 10354424      0 851960    0    0     0     0 8849 31376 28 67  6  0
> 1389799144.207531 1515 35      0 10318484      0 852092    0    0     0     0 7670 28332 31 69  0  0
> 1389799145.207852 1678 26      0 10303276      0 852196    0    0     0     0 7596 27208 31 69  0  0
> 1389799146.208176 1981 43      0 10264672      0 852284    0    0     0     0 7478 27313 31 69  0  0
> 1389799147.208500 1977 35      0 10299316      0 852380    0    0     0     0 8505 29552 30 70  0  0

That's for the data! Is it the per seconds or per 10 seconds?
Alex Shi Jan. 16, 2014, 3:07 a.m. UTC | #3
On 01/16/2014 11:01 AM, Fengguang Wu wrote:
> On Thu, Jan 16, 2014 at 10:46:01AM +0800, Alex Shi wrote:
>>>>>>>>>
>>>>>>>>> What's about the aim7 shell_rtns_1 and shared throughput?
>>>>>>>
>>>>>>> The throughputs remain the same.  We only report changed numbers.
>>>>>
>>>>> So many interrupt increase doesn't cause any performance change, that
>>>>> make more doubt of data correction.
>>>>> Could you like to give the typical vmstat output? Specially the
>>>>> sys/us/wa/id time percentages.
>>
>>> wfg@bee /lkp/result/lkp-ne04/micro/aim7/shell_rtns_1/x86_64-lkp/91dd08bd65052b483f96f75abcc93f2f1b67a62c/1% cat vmstat
>>> 1389799131.230965 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>>> 1389799131.231067  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>>> 1389799143.207206 1912 26      0 10354424      0 851960    0    0     0     0 8849 31376 28 67  6  0
>>> 1389799144.207531 1515 35      0 10318484      0 852092    0    0     0     0 7670 28332 31 69  0  0
>>> 1389799145.207852 1678 26      0 10303276      0 852196    0    0     0     0 7596 27208 31 69  0  0
>>> 1389799146.208176 1981 43      0 10264672      0 852284    0    0     0     0 7478 27313 31 69  0  0
>>> 1389799147.208500 1977 35      0 10299316      0 852380    0    0     0     0 8505 29552 30 70  0  0
>>
>> That's for the data!

Sorry for typo. I wanted to say 'Thanks for the data' not 'That'. :)
This data is good enough.
> 
> It does not matter in comparison POV. How do you know when aim starts
> the testing phase?
> 
>> Is it the per seconds or per 10 seconds?
> 
> It's per seconds. The first column has the time stamps.

Thanks!
> 
> Thanks,
> Fengguang
>
diff mbox

Patch

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2b216ad..046ca2c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4008,7 +4008,6 @@  static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)
        struct task_group *tg;
        unsigned long weight;
        int balanced;
-       int bias = 100 + (sd->imbalance_pct -100) / 2;
 
        /*
         * If we wake multiple tasks be careful to not bounce
@@ -4020,7 +4019,7 @@  static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)
        this_cpu  = smp_processor_id();
        prev_cpu  = task_cpu(p);
        load      = source_load(prev_cpu);
-       this_load = target_load(this_cpu, bias);
+       this_load = target_load(this_cpu, sd->imbalance_pct);
 
        /*
         * If sync wakeup then subtract the (maximum possible)
@@ -4055,7 +4054,7 @@  static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)
                this_eff_load *= this_load +
                        effective_load(tg, this_cpu, weight, weight);
 
-               prev_eff_load = bias;
+               prev_eff_load = 100 + (sd->imbalance_pct - 100) / 2;
                prev_eff_load *= power_of(this_cpu);
                prev_eff_load *= load + effective_load(tg, prev_cpu, 0, weight);
 
@@ -4100,7 +4099,6 @@  find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu)
 {
        struct sched_group *idlest = NULL, *group = sd->groups;
        unsigned long min_load = ULONG_MAX, this_load = 0;
-       int imbalance = 100 + (sd->imbalance_pct-100)/2;
 
        do {
                unsigned long load, avg_load;
@@ -4123,7 +4121,7 @@  find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu)
                        if (local_group)
                                load = source_load(i);
                        else
-                               load = target_load(i, imbalance);
+                               load = target_load(i, sd->imbalance_pct);
 
                        avg_load += load;
                }