public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: kernel test robot <rong.a.chen@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Will Deacon <will.deacon@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	tipbuild@zytor.com, lkp@01.org
Subject: Re: [locking/rwsem] 1b94536f2d: stress-ng.bad-altstack.ops_per_sec -32.7% regression
Date: Fri, 12 Apr 2019 12:43:03 -0400	[thread overview]
Message-ID: <40dc40d5-58ff-e5b9-4e33-b0ce08ca0521@redhat.com> (raw)
In-Reply-To: <20190412142005.GB24200@shao2-debian>

On 04/12/2019 10:20 AM, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -32.7% regression of stress-ng.bad-altstack.ops_per_sec due to commit:
>
>
> commit: 1b94536f2debc98260fb17b44f7f262e3336f7e0 ("locking/rwsem: Implement lock handoff to prevent lock starvation")
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.locking/core
>
> in testcase: stress-ng
> on test machine: 272 threads Intel(R) Xeon Phi(TM) CPU 7255 @ 1.10GHz with 112G memory
> with following parameters:
>
> 	nr_threads: 100%
> 	disk: 1HDD
> 	testtime: 5s
> 	class: memory
> 	cpufreq_governor: performance
>
>
>
>
> Details are as below:
> -------------------------------------------------------------------------------------------------->
>
>
> To reproduce:
>
>         git clone https://github.com/intel/lkp-tests.git
>         cd lkp-tests
>         bin/lkp install job.yaml  # job file is attached in this email
>         bin/lkp run     job.yaml
>
> =========================================================================================
> class/compiler/cpufreq_governor/disk/kconfig/nr_threads/rootfs/tbox_group/testcase/testtime:
>   memory/gcc-7/performance/1HDD/x86_64-rhel-7.6/100%/debian-x86_64-2018-04-03.cgz/lkp-knm02/stress-ng/5s
>
> commit: 
>   1bcfe0e4cb ("locking/rwsem: Improve scalability via a new locking scheme")
>   1b94536f2d ("locking/rwsem: Implement lock handoff to prevent lock starvation")
>
> 1bcfe0e4cb0efdba 1b94536f2debc98260fb17b44f7 
> ---------------- --------------------------- 
>        fail:runs  %reproduction    fail:runs
>            |             |             |    
>           1:4          -25%            :4     dmesg.WARNING:at_ip__mutex_lock/0x
>            :4           25%           1:4     kmsg.DHCP/BOOTP:Reply_not_for_us_on_eth#,op[#]xid[#]
>          %stddev     %change         %stddev
>              \          |                \  
>      52766 ± 19%     -32.8%      35434 ±  3%  stress-ng.bad-altstack.ops
>      10521 ± 19%     -32.7%       7081 ±  3%  stress-ng.bad-altstack.ops_per_sec
>      71472 ± 16%     -37.1%      44986        stress-ng.stackmmap.ops
>      14281 ± 16%     -37.0%       9001        stress-ng.stackmmap.ops_per_sec

The lock handoff patch does have the side effect of reducing throughput
for better fairness when there is extreme contention on a rwsem. I
believe later patches that enable reader optimistic spinning should
bring back some of the lost performance.

Cheers,
Longman

      reply	other threads:[~2019-04-12 16:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 14:20 [locking/rwsem] 1b94536f2d: stress-ng.bad-altstack.ops_per_sec -32.7% regression kernel test robot
2019-04-12 16:43 ` Waiman Long [this message]

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=40dc40d5-58ff-e5b9-4e33-b0ce08ca0521@redhat.com \
    --to=longman@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rong.a.chen@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tipbuild@zytor.com \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.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