All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: lkp@lists.01.org
Subject: Re: [sched/fair] b360fb5e59: stress-ng.vm-segv.ops_per_sec -13.9% regression
Date: Wed, 03 Mar 2021 18:34:13 +0000	[thread overview]
Message-ID: <jhjy2f46q8q.mognet@arm.com> (raw)
In-Reply-To: <jhjim6jhsfp.mognet@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On 23/02/21 12:36, Valentin Schneider wrote:
> On 23/02/21 10:30, kernel test robot wrote:
>> Greeting,
>>
>> FYI, we noticed a -13.9% regression of stress-ng.vm-segv.ops_per_sec due to commit:
>>
>>
>> commit: b360fb5e5954a8a440ef95bf11257e2e7ea90340 ("[PATCH v2 1/7] sched/fair: Ignore percpu threads for imbalance pulls")
>> url: https://github.com/0day-ci/linux/commits/Valentin-Schneider/sched-fair-misfit-task-load-balance-tweaks/20210219-211028
>> base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git c5e6fc08feb2b88dc5dac2f3c817e1c2a4cafda4
>>
>> in testcase: stress-ng
>> on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G memory
>> with following parameters:
>>
>>      nr_threads: 10%
>>      disk: 1HDD
>>      testtime: 60s
>>      fs: ext4
>>      class: vm
>>      test: vm-segv
>>      cpufreq_governor: performance
>>      ucode: 0x5003003
>>

So I've been running this on my 32 CPU arm64 desktop with:
  nr_threads: 10%
  nr_threads: 50%
  (20 iterations each)

In the 50% case I see a ~2% improvement, in the 10% a -0.3%
regression (another batch showed -0.08%)... Still far off from the reported
-14%. If it's really required I can go find an x86 box to test this on, but
so far it looks like a fluke.

WARNING: multiple messages have this Message-ID (diff)
From: Valentin Schneider <valentin.schneider@arm.com>
To: kernel test robot <oliver.sang@intel.com>
Cc: 0day robot <lkp@intel.com>, LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, ying.huang@intel.com, feng.tang@intel.com,
	zhengjun.xing@intel.com,
	Lingutla Chandrasekhar <clingutla@codeaurora.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Qais Yousef <qais.yousef@arm.com>,
	Quentin Perret <qperret@google.com>,
	Pavan Kondeti <pkondeti@codeaurora.org>,
	Rik van Riel <riel@surriel.com>,
	aubrey.li@linux.intel.com, yu.c.chen@intel.com
Subject: Re: [sched/fair]  b360fb5e59:  stress-ng.vm-segv.ops_per_sec -13.9% regression
Date: Wed, 03 Mar 2021 18:34:13 +0000	[thread overview]
Message-ID: <jhjy2f46q8q.mognet@arm.com> (raw)
In-Reply-To: <jhjim6jhsfp.mognet@arm.com>

On 23/02/21 12:36, Valentin Schneider wrote:
> On 23/02/21 10:30, kernel test robot wrote:
>> Greeting,
>>
>> FYI, we noticed a -13.9% regression of stress-ng.vm-segv.ops_per_sec due to commit:
>>
>>
>> commit: b360fb5e5954a8a440ef95bf11257e2e7ea90340 ("[PATCH v2 1/7] sched/fair: Ignore percpu threads for imbalance pulls")
>> url: https://github.com/0day-ci/linux/commits/Valentin-Schneider/sched-fair-misfit-task-load-balance-tweaks/20210219-211028
>> base: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git c5e6fc08feb2b88dc5dac2f3c817e1c2a4cafda4
>>
>> in testcase: stress-ng
>> on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G memory
>> with following parameters:
>>
>>      nr_threads: 10%
>>      disk: 1HDD
>>      testtime: 60s
>>      fs: ext4
>>      class: vm
>>      test: vm-segv
>>      cpufreq_governor: performance
>>      ucode: 0x5003003
>>

So I've been running this on my 32 CPU arm64 desktop with:
  nr_threads: 10%
  nr_threads: 50%
  (20 iterations each)

In the 50% case I see a ~2% improvement, in the 10% a -0.3%
regression (another batch showed -0.08%)... Still far off from the reported
-14%. If it's really required I can go find an x86 box to test this on, but
so far it looks like a fluke.

  reply	other threads:[~2021-03-03 18:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 12:59 [PATCH v2 0/7] sched/fair: misfit task load-balance tweaks Valentin Schneider
2021-02-19 12:59 ` [PATCH v2 1/7] sched/fair: Ignore percpu threads for imbalance pulls Valentin Schneider
2021-02-22  5:33   ` Pavan Kondeti
2021-02-23  2:30   ` [sched/fair] b360fb5e59: stress-ng.vm-segv.ops_per_sec -13.9% regression kernel test robot
2021-02-23  2:30     ` kernel test robot
2021-02-23 12:36     ` Valentin Schneider
2021-02-23 12:36       ` Valentin Schneider
2021-03-03 18:34       ` Valentin Schneider [this message]
2021-03-03 18:34         ` Valentin Schneider
2021-02-19 12:59 ` [PATCH v2 2/7] sched/fair: Clean up active balance nr_balance_failed trickery Valentin Schneider
2021-02-19 12:59 ` [PATCH v2 3/7] sched/fair: Add more sched_asym_cpucapacity static branch checks Valentin Schneider
2021-02-19 13:00 ` [PATCH v2 4/7] sched/fair: Introduce a CPU capacity comparison helper Valentin Schneider
2021-02-19 13:00 ` [PATCH v2 5/7] sched/fair: Employ capacity_greater() throughout load_balance() Valentin Schneider
2021-02-19 13:00 ` [PATCH v2 6/7] sched/fair: Filter out locally-unsolvable misfit imbalances Valentin Schneider
2021-02-19 13:00 ` [PATCH v2 7/7] sched/fair: Relax task_hot() for misfit tasks Valentin Schneider

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=jhjy2f46q8q.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=lkp@lists.01.org \
    /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.