From: Patrick Bellasi <patrick.bellasi@arm.com>
To: lkp@lists.01.org
Subject: Re: [lkp-robot] [sched/fair] d519329f72: unixbench.score -9.9% regression
Date: Wed, 24 Oct 2018 18:01:37 +0100 [thread overview]
Message-ID: <20181024170137.GA13236@e110439-lin> (raw)
In-Reply-To: <20181024064100.GA27054@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
On 24-Oct 14:41, Aaron Lu wrote:
> On Mon, Apr 02, 2018 at 11:20:00AM +0800, Ye, Xiaolong wrote:
> >
> > Greeting,
> >
> > FYI, we noticed a -9.9% regression of unixbench.score due to commit:
> >
> >
> > commit: d519329f72a6f36bc4f2b85452640cfe583b4f81 ("sched/fair: Update util_est only on util_avg updates")
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >
> > in testcase: unixbench
> > on test machine: 8 threads Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz with 6G memory
> > with following parameters:
> >
> > runtime: 300s
> > nr_task: 100%
> > test: execl
> >
> > test-description: UnixBench is the original BYTE UNIX benchmark suite aims to test performance of Unix-like system.
> > test-url: https://github.com/kdlucas/byte-unixbench
Hi Aaron,
> I tested this workload on different machines with this commit
> d519329f72a6f36bc4f2b85452 and its parent a07630b8b2c16f82, I also
> tested with v4.19-rc8 to see if the regression is gone -
> the performance drop is there with v4.19-rc8 and with different
> machines so I assume this regression is not solved yet.
>
> Here are detailed data:
>
> cmdline used to run this workload:
> ./Run execl -c $nr_cpu -i 30
I had a better look into this issue and found that something like this
could be the cure for the execl throughput regression:
---8<---
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 908c9cdae2f0..c34d41b542fc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6258,8 +6258,17 @@ static unsigned long cpu_util_wake(int cpu, struct task_struct *p)
* covered by the following code when estimated utilization is
* enabled.
*/
- if (sched_feat(UTIL_EST))
- util = max(util, READ_ONCE(cfs_rq->avg.util_est.enqueued));
+ if (sched_feat(UTIL_EST)) {
+ unsigned int estimated =
+ READ_ONCE(cfs_rq->avg.util_est.enqueued);
+
+ if (unlikely(current == p)) {
+ estimated -= min_t(unsigned int, estimated,
+ (_task_util_est(p) | UTIL_AVG_UNCHANGED));
+ }
+
+ util = max(util, estimated);
+ }
/*
* Utilization (estimated) can exceed the CPU capacity, thus let's
---8<---
I'll test this better on a machine on my side and send out a proper
patch by tomorrow.
> Please let me know if you need other information, thanks.
Would be nice if you can test the above on your side too.
Cheers Patrick
--
#include <best/regards.h>
Patrick Bellasi
WARNING: multiple messages have this Message-ID (diff)
From: Patrick Bellasi <patrick.bellasi@arm.com>
To: Aaron Lu <aaron.lu@intel.com>
Cc: "Ye, Xiaolong" <xiaolong.ye@intel.com>,
Joel Fernandes <joelaf@google.com>,
Juri Lelli <juri.lelli@redhat.com>, Todd Kjos <tkjos@android.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Peter Zijlstra <peterz@infradead.org>,
Paul Turner <pjt@google.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steve Muckle <smuckle@google.com>, "lkp@01.org" <lkp@01.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Chris Redpath <chris.redpath@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [LKP] [lkp-robot] [sched/fair] d519329f72: unixbench.score -9.9% regression
Date: Wed, 24 Oct 2018 18:01:37 +0100 [thread overview]
Message-ID: <20181024170137.GA13236@e110439-lin> (raw)
In-Reply-To: <20181024064100.GA27054@intel.com>
On 24-Oct 14:41, Aaron Lu wrote:
> On Mon, Apr 02, 2018 at 11:20:00AM +0800, Ye, Xiaolong wrote:
> >
> > Greeting,
> >
> > FYI, we noticed a -9.9% regression of unixbench.score due to commit:
> >
> >
> > commit: d519329f72a6f36bc4f2b85452640cfe583b4f81 ("sched/fair: Update util_est only on util_avg updates")
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >
> > in testcase: unixbench
> > on test machine: 8 threads Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz with 6G memory
> > with following parameters:
> >
> > runtime: 300s
> > nr_task: 100%
> > test: execl
> >
> > test-description: UnixBench is the original BYTE UNIX benchmark suite aims to test performance of Unix-like system.
> > test-url: https://github.com/kdlucas/byte-unixbench
Hi Aaron,
> I tested this workload on different machines with this commit
> d519329f72a6f36bc4f2b85452 and its parent a07630b8b2c16f82, I also
> tested with v4.19-rc8 to see if the regression is gone -
> the performance drop is there with v4.19-rc8 and with different
> machines so I assume this regression is not solved yet.
>
> Here are detailed data:
>
> cmdline used to run this workload:
> ./Run execl -c $nr_cpu -i 30
I had a better look into this issue and found that something like this
could be the cure for the execl throughput regression:
---8<---
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 908c9cdae2f0..c34d41b542fc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6258,8 +6258,17 @@ static unsigned long cpu_util_wake(int cpu, struct task_struct *p)
* covered by the following code when estimated utilization is
* enabled.
*/
- if (sched_feat(UTIL_EST))
- util = max(util, READ_ONCE(cfs_rq->avg.util_est.enqueued));
+ if (sched_feat(UTIL_EST)) {
+ unsigned int estimated =
+ READ_ONCE(cfs_rq->avg.util_est.enqueued);
+
+ if (unlikely(current == p)) {
+ estimated -= min_t(unsigned int, estimated,
+ (_task_util_est(p) | UTIL_AVG_UNCHANGED));
+ }
+
+ util = max(util, estimated);
+ }
/*
* Utilization (estimated) can exceed the CPU capacity, thus let's
---8<---
I'll test this better on a machine on my side and send out a proper
patch by tomorrow.
> Please let me know if you need other information, thanks.
Would be nice if you can test the above on your side too.
Cheers Patrick
--
#include <best/regards.h>
Patrick Bellasi
next prev parent reply other threads:[~2018-10-24 17:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-02 3:20 [lkp-robot] [sched/fair] d519329f72: unixbench.score -9.9% regression kernel test robot
2018-04-02 3:20 ` kernel test robot
2018-04-03 11:43 ` Patrick Bellasi
2018-04-03 11:43 ` Patrick Bellasi
2018-04-04 6:14 ` Ye Xiaolong
2018-04-04 6:14 ` Ye Xiaolong
2018-10-24 6:41 ` Aaron Lu
2018-10-24 6:41 ` [LKP] " Aaron Lu
2018-10-24 17:01 ` Patrick Bellasi [this message]
2018-10-24 17:01 ` Patrick Bellasi
2018-10-25 8:56 ` Aaron Lu
2018-10-25 8:56 ` [LKP] " Aaron Lu
2018-10-25 9:31 ` Patrick Bellasi
2018-10-25 9:31 ` [LKP] " Patrick Bellasi
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=20181024170137.GA13236@e110439-lin \
--to=patrick.bellasi@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.