Re: [LKP] [lkp-robot] [sched/cfs] 625ed2bf04: unixbench.score -7.4% regression

From: "Huang\, Ying" <ying.huang@intel.com>
To: kernel test robot <xiaolong.ye@intel.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Peter Zijlstra <peterz@infradead.org>, "lkp\@01.org" <lkp@01.org>,
	Mike Galbraith <efault@gmx.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: [LKP] [lkp-robot] [sched/cfs] 625ed2bf04: unixbench.score -7.4% regression
Date: Mon, 28 Aug 2017 13:57:39 +0800	[thread overview]
Message-ID: <8760d8i698.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20170519060706.GU568@yexl-desktop> (kernel test robot's message of "Fri, 19 May 2017 14:07:06 +0800")

kernel test robot <xiaolong.ye@intel.com> writes:

> Greeting,
>
> FYI, we noticed a -7.4% regression of unixbench.score due to commit:
>
>
> commit: 625ed2bf049d5a352c1bcca962d6e133454eaaff ("sched/cfs: Make util/load_avg more stable")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase: unixbench
> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 64G memory
> with following parameters:
>
> 	runtime: 300s
> 	nr_task: 100%
> 	test: spawn
> 	cpufreq_governor: performance
>
> test-description: UnixBench is the original BYTE UNIX benchmark suite aims to test performance of Unix-like system.
>

This has been merged by v4.13-rc1, so we checked it again.  If my
understanding were correct, the patch changes the algorithm to calculate
the load of CPU, so it influences the load balance behavior for this
test case.

      4.73 ±  8%     -31.3%       3.25 ± 10%  sched_debug.cpu.nr_running.max
      0.95 ±  5%     -29.0%       0.67 ±  4%  sched_debug.cpu.nr_running.stddev

As above, the effect is that the tasks are distributed into more CPUs,
that is, system is more balanced.  But this triggered more contention on
tasklist_lock, so hurt the unixbench score, as below.

     26.60           -10.6       16.05        perf-profile.calltrace.cycles-pp.intel_idle.cpuidle_enter_state.cpuidle_enter.call_cpuidle.do_idle
     10.10            +2.4       12.53        perf-profile.calltrace.cycles-pp._raw_write_lock_irq.do_exit.do_group_exit.sys_exit_group.entry_SYSCALL_64_fastpath
      8.03            +2.6       10.63        perf-profile.calltrace.cycles-pp._raw_write_lock_irq.release_task.wait_consider_task.do_wait.sys_wait4
     17.98            +5.2       23.14        perf-profile.calltrace.cycles-pp._raw_read_lock.do_wait.sys_wait4.entry_SYSCALL_64_fastpath
      7.47            +5.9       13.33        perf-profile.calltrace.cycles-pp._raw_write_lock_irq.copy_process._do_fork.sys_clone.do_syscall_64

The patch makes the tasks distributed more balanced, so I think
scheduler do better job here.  The problem is that the tasklist_lock
isn't scalable.  But considering this is only a micro-benchmark which
specially exercises fork/exit/wait syscall, this may be not a big
problem in reality.

So, all in all, I think we can ignore this regression.

Best Regards,
Huang, Ying