All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: huang ying <huang.ying.caritas@gmail.com>
Cc: Ding Tianhong <dingtianhong@huawei.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Waiman Long <waiman.long@hpe.com>, Jason Low <jason.low2@hp.com>,
	Ingo Molnar <mingo@redhat.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Davidlohr Bueso" <dave@stgolabs.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <Will.Deacon@arm.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Waiman Long <Waiman.Long@hp.com>,
	Huang Ying <ying.huang@intel.com>
Subject: Re: [PATCH RFC] locking/mutexes: don't spin on owner when wait list is not NULL.
Date: Mon, 01 Feb 2016 11:35:42 +0800	[thread overview]
Message-ID: <87d1shxfu9.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <CAC=cRTNWnt3UUdN4bRiyGd+ySndu078gnhpAdNWcOwvXnv-s1g@mail.gmail.com> (huang ying's message of "Mon, 1 Feb 2016 11:29:13 +0800")

huang ying <huang.ying.caritas@gmail.com> writes:

> On Sat, Jan 30, 2016 at 9:18 AM, Ding Tianhong <dingtianhong@huawei.com> wrote:
>> On 2016/1/29 17:53, Peter Zijlstra wrote:
>>> On Sun, Jan 24, 2016 at 04:03:50PM +0800, Ding Tianhong wrote:
>>>
>>>> looks good to me, I will try this solution and report the result, thanks everyone.
>>>
>>> Did you get a change to run with this?
>>>
>>> .
>>>
>>
>> I backport this patch to 3.10 lts kernel, and didn't change any
>> logic, Till now, the patch works fine to me, and no need to change
>> anything,
>> So I think this patch is no problem, could you formal release this patch to the latest kernel? :)
>>
>> Thanks.
>> Ding
>>
>>
>
> The original patch from Tianhong triggered a performance regression
> because the optimistic spinning is turned off in effect.  I tested
> Peter's patch with same configuration and there show no regression.
> So I think the patch keep the optimistic spinning.  Test result
> details will be in the next email.

Here is the detailed test result:

=========================================================================================
compiler/cpufreq_governor/kconfig/nr_task/rootfs/tbox_group/test/testcase:
  gcc-4.9/performance/x86_64-rhel/100%/debian-x86_64-2015-02-07.cgz/lkp-ivb-d01/fstime/unixbench

commit: 
  v4.4
  1db66c17114d5437c0757d6792c0d8923192ecd6

            v4.4 1db66c17114d5437c0757d6792 
---------------- -------------------------- 
         %stddev     %change         %stddev
             \          |                \  
    371269 ± 10%     -93.2%      25080 ±  4%  unixbench.time.voluntary_context_switches
    371269 ± 10%     -93.2%      25080 ±  4%  time.voluntary_context_switches
      6189 ±  8%     -76.4%       1463 ±  6%  vmstat.system.cs
      5706 ±  0%      -1.7%       5608 ±  0%  vmstat.system.in
    113680 ± 12%     -73.5%      30086 ±  1%  cpuidle.C1-IVB.usage
   1515925 ± 20%     +68.3%    2552001 ± 11%  cpuidle.C1E-IVB.time
   1227221 ± 20%     -51.7%     592695 ± 17%  cpuidle.C3-IVB.time
      2697 ± 10%     -77.8%     598.33 ± 10%  cpuidle.C3-IVB.usage
     15173 ±  6%     -23.1%      11663 ±  1%  cpuidle.C6-IVB.usage
     34.38 ± 27%     -35.0%      22.33 ±  2%  cpuidle.POLL.usage
     61.92 ±  9%     +14.3%      70.78 ±  7%  sched_debug.cfs_rq:/.load_avg.min
     40.85 ± 29%     +27.3%      52.00 ± 10%  sched_debug.cfs_rq:/.runnable_load_avg.2
     -1949 ±-37%     -64.6%    -690.19 ±-134%  sched_debug.cfs_rq:/.spread0.4
     -1773 ±-29%     -85.6%    -256.00 ±-388%  sched_debug.cfs_rq:/.spread0.7
     -2478 ±-26%     -49.5%      -1251 ±-66%  sched_debug.cfs_rq:/.spread0.min
     61.95 ±  9%     +14.8%      71.11 ±  7%  sched_debug.cfs_rq:/.tg_load_avg_contrib.min
    396962 ± 12%     +27.9%     507573 ± 10%  sched_debug.cpu.avg_idle.0
    432973 ± 18%     +45.3%     629147 ± 12%  sched_debug.cpu.avg_idle.6
    448566 ±  3%     +11.5%     499990 ±  0%  sched_debug.cpu.avg_idle.avg
     45.31 ±  5%      -9.5%      41.00 ±  3%  sched_debug.cpu.cpu_load[3].7
     52204 ± 10%     -49.9%      26173 ± 34%  sched_debug.cpu.nr_switches.0
     50383 ± 12%     -57.6%      21353 ± 15%  sched_debug.cpu.nr_switches.1
     45425 ± 16%     -68.5%      14325 ± 28%  sched_debug.cpu.nr_switches.2
     43069 ± 20%     -65.5%      14852 ± 41%  sched_debug.cpu.nr_switches.3
     40285 ± 16%     -70.4%      11905 ± 47%  sched_debug.cpu.nr_switches.4
     40732 ± 13%     -75.8%       9872 ± 39%  sched_debug.cpu.nr_switches.5
     43011 ± 19%     -80.0%       8607 ± 42%  sched_debug.cpu.nr_switches.6
     38076 ± 12%     -75.9%       9167 ± 40%  sched_debug.cpu.nr_switches.7
     44148 ±  7%     -67.1%      14532 ±  6%  sched_debug.cpu.nr_switches.avg
     59877 ±  8%     -51.3%      29146 ± 21%  sched_debug.cpu.nr_switches.max
     33672 ±  9%     -83.0%       5718 ±  4%  sched_debug.cpu.nr_switches.min
     -0.62 ±-1411%   -2212.5%      13.00 ± 16%  sched_debug.cpu.nr_uninterruptible.0
     -1.23 ±-582%   -1318.8%      15.00 ± 35%  sched_debug.cpu.nr_uninterruptible.1
      2.54 ±263%    +267.7%       9.33 ± 91%  sched_debug.cpu.nr_uninterruptible.2
      0.31 ±2966%   -5841.7%     -17.67 ±-19%  sched_debug.cpu.nr_uninterruptible.5
      9.84 ± 19%     +70.4%      16.76 ±  5%  sched_debug.cpu.nr_uninterruptible.stddev
    116287 ±  4%     -20.9%      91972 ±  9%  sched_debug.cpu.sched_count.0
     50411 ± 12%     -57.6%      21382 ± 15%  sched_debug.cpu.sched_count.1
     45453 ± 16%     -68.4%      14356 ± 28%  sched_debug.cpu.sched_count.2
     43098 ± 20%     -65.5%      14888 ± 41%  sched_debug.cpu.sched_count.3
     40314 ± 16%     -70.4%      11934 ± 47%  sched_debug.cpu.sched_count.4
     40761 ± 13%     -75.7%       9896 ± 39%  sched_debug.cpu.sched_count.5
     43041 ± 19%     -79.9%       8636 ± 42%  sched_debug.cpu.sched_count.6
     38105 ± 12%     -75.9%       9193 ± 40%  sched_debug.cpu.sched_count.7
     52184 ±  6%     -56.3%      22782 ±  4%  sched_debug.cpu.sched_count.avg
    116288 ±  4%     -20.9%      91972 ±  9%  sched_debug.cpu.sched_count.max
     33701 ±  9%     -82.9%       5746 ±  4%  sched_debug.cpu.sched_count.min
     22760 ± 10%     -63.0%       8418 ± 40%  sched_debug.cpu.sched_goidle.0
     23319 ± 13%     -60.9%       9114 ± 22%  sched_debug.cpu.sched_goidle.1
     21273 ± 17%     -80.4%       4169 ± 13%  sched_debug.cpu.sched_goidle.2
     19993 ± 19%     -67.8%       6429 ± 45%  sched_debug.cpu.sched_goidle.3
     18614 ± 17%     -85.0%       2788 ± 29%  sched_debug.cpu.sched_goidle.4
     18921 ± 12%     -86.7%       2520 ± 15%  sched_debug.cpu.sched_goidle.5
     20131 ± 17%     -82.1%       3596 ± 52%  sched_debug.cpu.sched_goidle.6
     17861 ± 12%     -86.9%       2334 ± 14%  sched_debug.cpu.sched_goidle.7
     20359 ±  8%     -75.8%       4921 ±  5%  sched_debug.cpu.sched_goidle.avg
     26477 ± 10%     -60.2%      10539 ± 21%  sched_debug.cpu.sched_goidle.max
     15845 ± 10%     -87.2%       2033 ±  4%  sched_debug.cpu.sched_goidle.min
     29043 ± 15%     -58.8%      11958 ± 26%  sched_debug.cpu.ttwu_count.0
     24191 ± 10%     -68.8%       7547 ± 27%  sched_debug.cpu.ttwu_count.1
     21313 ± 11%     -72.7%       5819 ± 24%  sched_debug.cpu.ttwu_count.2
     21487 ± 13%     -61.4%       8296 ± 43%  sched_debug.cpu.ttwu_count.3
     19644 ± 15%     -54.4%       8967 ± 79%  sched_debug.cpu.ttwu_count.4
     20786 ± 15%     -69.2%       6409 ± 58%  sched_debug.cpu.ttwu_count.5
     20435 ± 17%     -79.3%       4231 ± 58%  sched_debug.cpu.ttwu_count.6
     19293 ± 17%     -77.0%       4432 ± 55%  sched_debug.cpu.ttwu_count.7
     22024 ±  7%     -67.3%       7207 ±  6%  sched_debug.cpu.ttwu_count.avg
     31009 ±  9%     -45.2%      17008 ± 17%  sched_debug.cpu.ttwu_count.max
     16791 ± 10%     -85.1%       2494 ±  5%  sched_debug.cpu.ttwu_count.min
      3084 ±  8%     +25.5%       3870 ±  9%  sched_debug.cpu.ttwu_local.avg

The URL of the original regression report email:

https://lists.01.org/pipermail/lkp/2016-January/003442.html

Best Regards,
Huang, Ying

  reply	other threads:[~2016-02-01  3:35 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21  9:29 [PATCH RFC] locking/mutexes: don't spin on owner when wait list is not NULL Ding Tianhong
2016-01-21 21:23 ` Tim Chen
2016-01-22  2:41   ` Paul E. McKenney
2016-01-22  2:48     ` Davidlohr Bueso
2016-01-22  3:13       ` Paul E. McKenney
2016-01-21 23:02 ` Waiman Long
2016-01-22  6:09   ` Davidlohr Bueso
2016-01-22 13:38     ` Waiman Long
2016-01-22 16:46       ` Davidlohr Bueso
2016-01-25  2:23         ` [PATCH] locking/mutex: Allow next waiter lockless wakeup Davidlohr Bueso
2016-01-25 23:02           ` Waiman Long
2016-02-29 11:21           ` [tip:locking/core] " tip-bot for Davidlohr Bueso
2016-01-22  8:54   ` [PATCH RFC] locking/mutexes: don't spin on owner when wait list is not NULL Peter Zijlstra
2016-01-22 10:20     ` Jason Low
2016-01-22 10:53       ` Peter Zijlstra
2016-01-22 10:56         ` Peter Zijlstra
2016-01-22 11:06           ` Peter Zijlstra
2016-01-22 13:59             ` Waiman Long
2016-01-24  8:03               ` Ding Tianhong
2016-01-29  9:53                 ` Peter Zijlstra
2016-01-30  1:18                   ` Ding Tianhong
2016-02-01  3:29                     ` huang ying
2016-02-01  3:35                       ` Huang, Ying [this message]
2016-02-01 10:08                     ` [PATCH] locking/mutex: Avoid spinner vs waiter starvation Peter Zijlstra
2016-02-02 21:19                       ` Davidlohr Bueso
2016-02-03  7:10                         ` Ding Tianhong
2016-02-03 19:24                           ` Davidlohr Bueso
2016-02-04  1:20                             ` Ding Tianhong
2016-02-12 18:33                               ` Waiman Long
2016-02-03 22:07                         ` Waiman Long
2016-02-04  1:35                       ` Jason Low
2016-02-04  8:55                         ` huang ying
2016-02-04 22:49                           ` Jason Low
2016-01-22 13:41     ` [PATCH RFC] locking/mutexes: don't spin on owner when wait list is not NULL Waiman Long
  -- strict thread matches above, loose matches on Subject: below --
2016-01-21  6:53 [PATCH RFC ] " Ding Tianhong
2016-01-21  7:29 ` Ingo Molnar
2016-01-21  9:04   ` Ding Tianhong

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=87d1shxfu9.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=Waiman.Long@hp.com \
    --cc=Will.Deacon@arm.com \
    --cc=dave@stgolabs.net \
    --cc=dingtianhong@huawei.com \
    --cc=huang.ying.caritas@gmail.com \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulmck@us.ibm.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=waiman.long@hpe.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.