Hi Peter,
I have compiled your version of linux kernel and run the SPECjvm2008
tests. Results are fine, performance is at the level of 4.6 kernel.
$ git rev-parse HEAD
02548776ded1185e6e16ad0a475481e982741ee9
Jirka
On Fri, Jun 24, 2016 at 5:54 PM, Peter Zijlstra
Hi Peter,
I have compiled your version of linux kernel and run the SPECjvm2008
tests. Results are fine, performance is at the level of 4.6 kernel.
$ git rev-parse HEAD
02548776ded1185e6e16ad0a475481e982741ee9
Jirka
On Fri, Jun 24, 2016 at 5:54 PM, Peter Zijlstra wrote:
> On Fri, Jun 24,
On Fri, Jun 24, 2016 at 03:42:26PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct task_group
> > > *tg, struct
On Fri, Jun 24, 2016 at 03:42:26PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct task_group
> > > *tg, struct
On Fri, Jun 24, 2016 at 03:23:37PM +0200, Vincent Guittot wrote:
> > It seemed like a simple and cheap way to increase accuracy, nothing more
> > behind it until the commit you referred to.
>
> Thanks for the clarification.
> I thought that the difference should always be smaller than 1/64th of
>
On Fri, Jun 24, 2016 at 03:23:37PM +0200, Vincent Guittot wrote:
> > It seemed like a simple and cheap way to increase accuracy, nothing more
> > behind it until the commit you referred to.
>
> Thanks for the clarification.
> I thought that the difference should always be smaller than 1/64th of
>
On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct task_group
> > *tg, struct cfs_rq *cfs_rq)
> > */
> > tg_weight =
On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct task_group
> > *tg, struct cfs_rq *cfs_rq)
> > */
> > tg_weight =
On Fri, Jun 24, 2016 at 03:23:37PM +0200, Vincent Guittot wrote:
> On 24 June 2016 at 15:09, Peter Zijlstra wrote:
> > On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> >
> >> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >> > index
On Fri, Jun 24, 2016 at 03:23:37PM +0200, Vincent Guittot wrote:
> On 24 June 2016 at 15:09, Peter Zijlstra wrote:
> > On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> >
> >> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >> > index 22d64b3f5876..d4f6fb2f3057 100644
On 24 June 2016 at 15:09, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
>
>> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> > index 22d64b3f5876..d4f6fb2f3057 100644
>> > --- a/kernel/sched/fair.c
>> > +++
On 24 June 2016 at 15:09, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
>
>> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> > index 22d64b3f5876..d4f6fb2f3057 100644
>> > --- a/kernel/sched/fair.c
>> > +++ b/kernel/sched/fair.c
>> > @@
On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 22d64b3f5876..d4f6fb2f3057 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct
On Fri, Jun 24, 2016 at 02:44:07PM +0200, Vincent Guittot wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 22d64b3f5876..d4f6fb2f3057 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2484,7 +2484,7 @@ static inline long calc_tg_weight(struct
Hi Peter,
the proposed patch has fixed the performance issue. I have applied the
patch to v4.7-rc4
Jirka
On Fri, Jun 24, 2016 at 2:44 PM, Vincent Guittot
wrote:
> Hi Peter,
>
> On 24 June 2016 at 14:02, Peter Zijlstra wrote:
>> On Fri, Jun 24,
Hi Peter,
the proposed patch has fixed the performance issue. I have applied the
patch to v4.7-rc4
Jirka
On Fri, Jun 24, 2016 at 2:44 PM, Vincent Guittot
wrote:
> Hi Peter,
>
> On 24 June 2016 at 14:02, Peter Zijlstra wrote:
>> On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
>>>
Hi Peter,
On 24 June 2016 at 14:02, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
>> Hi Peter,
>>
>> thanks a lot for looking into it!
>>
>> I have tried to disable autogroups
>>
>> sysctl -w kernel.sched_autogroup_enabled=0
>>
>> and
Hi Peter,
On 24 June 2016 at 14:02, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
>> Hi Peter,
>>
>> thanks a lot for looking into it!
>>
>> I have tried to disable autogroups
>>
>> sysctl -w kernel.sched_autogroup_enabled=0
>>
>> and I can confirm that
OK, I have applied to v4.7-rc4 via git am
Compiling kernel, should have the results soon.
Jirka
On Fri, Jun 24, 2016 at 2:09 PM, Jirka Hladky wrote:
> Thank you Peter!
>
> Should I apply it to v4.7-rc4 ?
>
> Jirka
>
> On Fri, Jun 24, 2016 at 2:02 PM, Peter Zijlstra
OK, I have applied to v4.7-rc4 via git am
Compiling kernel, should have the results soon.
Jirka
On Fri, Jun 24, 2016 at 2:09 PM, Jirka Hladky wrote:
> Thank you Peter!
>
> Should I apply it to v4.7-rc4 ?
>
> Jirka
>
> On Fri, Jun 24, 2016 at 2:02 PM, Peter Zijlstra wrote:
>> On Fri, Jun 24,
On Fri, Jun 24, 2016 at 02:09:30PM +0200, Jirka Hladky wrote:
> Thank you Peter!
>
> Should I apply it to v4.7-rc4 ?
It does indeed apply to v4.7-rc4, although I only tested it against
tip/master.
On Fri, Jun 24, 2016 at 02:09:30PM +0200, Jirka Hladky wrote:
> Thank you Peter!
>
> Should I apply it to v4.7-rc4 ?
It does indeed apply to v4.7-rc4, although I only tested it against
tip/master.
Thank you Peter!
Should I apply it to v4.7-rc4 ?
Jirka
On Fri, Jun 24, 2016 at 2:02 PM, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
>> Hi Peter,
>>
>> thanks a lot for looking into it!
>>
>> I have tried to disable autogroups
>>
Thank you Peter!
Should I apply it to v4.7-rc4 ?
Jirka
On Fri, Jun 24, 2016 at 2:02 PM, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
>> Hi Peter,
>>
>> thanks a lot for looking into it!
>>
>> I have tried to disable autogroups
>>
>> sysctl -w
On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
> Hi Peter,
>
> thanks a lot for looking into it!
>
> I have tried to disable autogroups
>
> sysctl -w kernel.sched_autogroup_enabled=0
>
> and I can confirm that performance is then back at level as in 4.6 kernel.
So unless the
On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
> Hi Peter,
>
> thanks a lot for looking into it!
>
> I have tried to disable autogroups
>
> sysctl -w kernel.sched_autogroup_enabled=0
>
> and I can confirm that performance is then back at level as in 4.6 kernel.
So unless the
I had a look and
CONFIG_SCHED_AUTOGROUP=y
is used both in RHEL6 and RHEL7. We compile the upstream kernels with
config derived from RHEL7 config file.
Jirka
On Fri, Jun 24, 2016 at 10:08 AM, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky
I had a look and
CONFIG_SCHED_AUTOGROUP=y
is used both in RHEL6 and RHEL7. We compile the upstream kernels with
config derived from RHEL7 config file.
Jirka
On Fri, Jun 24, 2016 at 10:08 AM, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
>> I have
On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
> I have double checked default settings and
>
> kernel.sched_autogroup_enabled
>
> is by default ON both in 4.6 and 4.7 kernel.
Yeah, if you enable that CONFIG its default enabled. In any case, I'll
go trawl through the cgroup code
On Fri, Jun 24, 2016 at 09:44:41AM +0200, Jirka Hladky wrote:
> I have double checked default settings and
>
> kernel.sched_autogroup_enabled
>
> is by default ON both in 4.6 and 4.7 kernel.
Yeah, if you enable that CONFIG its default enabled. In any case, I'll
go trawl through the cgroup code
Hi Peter,
thanks a lot for looking into it!
I have tried to disable autogroups
sysctl -w kernel.sched_autogroup_enabled=0
and I can confirm that performance is then back at level as in 4.6 kernel.
I have double checked default settings and
kernel.sched_autogroup_enabled
is by default ON
Hi Peter,
thanks a lot for looking into it!
I have tried to disable autogroups
sysctl -w kernel.sched_autogroup_enabled=0
and I can confirm that performance is then back at level as in 4.6 kernel.
I have double checked default settings and
kernel.sched_autogroup_enabled
is by default ON
On Thu, Jun 23, 2016 at 08:33:18PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote:
>
> > > What kind of config and userspace setup? Do you run this cruft in a
> > > cgroup of sorts?
> >
> > No, we don't do any special setup except to control the
On Thu, Jun 23, 2016 at 08:33:18PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote:
>
> > > What kind of config and userspace setup? Do you run this cruft in a
> > > cgroup of sorts?
> >
> > No, we don't do any special setup except to control the
On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote:
> > What kind of config and userspace setup? Do you run this cruft in a
> > cgroup of sorts?
>
> No, we don't do any special setup except to control the number of threads.
OK, so I'm fairly certain you _do_ run in a cgroup, because
On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote:
> > What kind of config and userspace setup? Do you run this cruft in a
> > cgroup of sorts?
>
> No, we don't do any special setup except to control the number of threads.
OK, so I'm fairly certain you _do_ run in a cgroup, because
On Wed, Jun 22, 2016 at 04:41:06PM +0200, Jirka Hladky wrote:
> This commit is bad:
> 2159197 - Peter Zijlstra, 8 weeks ago : sched/core: Enable increased
> load resolution on 64-bit kernels
>
> Could you please have a look?
Yes, that is indeed the culprit.
The below 'revert' makes it go fast
On Wed, Jun 22, 2016 at 04:41:06PM +0200, Jirka Hladky wrote:
> This commit is bad:
> 2159197 - Peter Zijlstra, 8 weeks ago : sched/core: Enable increased
> load resolution on 64-bit kernels
>
> Could you please have a look?
Yes, that is indeed the culprit.
The below 'revert' makes it go fast
Hi Peter,
the kernel I got with bisecting does not work - I'm getting kernel
panic during the boot.
In any case, the regression was introduced between
git bisect good 64b7aad
git bisect bad 2159197
This commit is good:
64b7aad - Ingo Molnar, 7 weeks ago : Merge branch 'sched/urgent' into
Hi Peter,
the kernel I got with bisecting does not work - I'm getting kernel
panic during the boot.
In any case, the regression was introduced between
git bisect good 64b7aad
git bisect bad 2159197
This commit is good:
64b7aad - Ingo Molnar, 7 weeks ago : Merge branch 'sched/urgent' into
OK, I have reviewed my results once again:
This commit is fine:
64b7aad - Ingo Molnar, 7 weeks ago : Merge branch 'sched/urgent' into
sched/core, to pick up fixes before applying new changes
This version has already a problem:
2159197 - Peter Zijlstra, 8 weeks ago : sched/core: Enable increased
OK, I have reviewed my results once again:
This commit is fine:
64b7aad - Ingo Molnar, 7 weeks ago : Merge branch 'sched/urgent' into
sched/core, to pick up fixes before applying new changes
This version has already a problem:
2159197 - Peter Zijlstra, 8 weeks ago : sched/core: Enable increased
Hi Peter,
crap - I have done bisecting manually (not using git bisect) and I
have probably done some mistake.
Commits (git checkout ) for which I got BAD results:
2159197d66770ec01f75c93fb11dc66df81fd45b
6ecdd74962f246dfe8750b7bea481a1c0816315d
Commits (git checkout ) for which I got GOOD
Hi Peter,
crap - I have done bisecting manually (not using git bisect) and I
have probably done some mistake.
Commits (git checkout ) for which I got BAD results:
2159197d66770ec01f75c93fb11dc66df81fd45b
6ecdd74962f246dfe8750b7bea481a1c0816315d
Commits (git checkout ) for which I got GOOD
On Wed, Jun 22, 2016 at 11:52:45AM +0200, Jirka Hladky wrote:
> Hi Peter,
>
> the performance regression has been caused by this commit
>
> =
> commit 6ecdd74962f246dfe8750b7bea481a1c0816315d
> Author: Yuyang Du
> Date: Tue
On Wed, Jun 22, 2016 at 11:52:45AM +0200, Jirka Hladky wrote:
> Hi Peter,
>
> the performance regression has been caused by this commit
>
> =
> commit 6ecdd74962f246dfe8750b7bea481a1c0816315d
> Author: Yuyang Du
> Date: Tue Apr 5 12:12:26 2016
Hi Peter,
the performance regression has been caused by this commit
=
commit 6ecdd74962f246dfe8750b7bea481a1c0816315d
Author: Yuyang Du
Date: Tue Apr 5 12:12:26 2016 +0800
sched/fair: Generalize the load/util averages
Hi Peter,
the performance regression has been caused by this commit
=
commit 6ecdd74962f246dfe8750b7bea481a1c0816315d
Author: Yuyang Du
Date: Tue Apr 5 12:12:26 2016 +0800
sched/fair: Generalize the load/util averages resolution definition
Hi Branimir,
I don't think that it's related. The regression has happened in one of
these two commits:
$ git log --pretty=oneline
e7904a28f5331c21d17af638cb477c83662e3cb6..6ecdd74962f246dfe8750b7bea481a1c0816315d
6ecdd74962f246dfe8750b7bea481a1c0816315d sched/fair: Generalize the
load/util
Hi Branimir,
I don't think that it's related. The regression has happened in one of
these two commits:
$ git log --pretty=oneline
e7904a28f5331c21d17af638cb477c83662e3cb6..6ecdd74962f246dfe8750b7bea481a1c0816315d
6ecdd74962f246dfe8750b7bea481a1c0816315d sched/fair: Generalize the
load/util
Hi Peter,
please find the reproducer script attached. My command to reproduce the bug is:
./run-specjvm.sh --benchmarkThreads 32 --iterations 1 --iterationTime
180 --warmuptime 90 xml.transform xml.validation
I run just xml benchmarks to speed up the runtime.
Please check
Hi Peter,
please find the reproducer script attached. My command to reproduce the bug is:
./run-specjvm.sh --benchmarkThreads 32 --iterations 1 --iterationTime
180 --warmuptime 90 xml.transform xml.validation
I run just xml benchmarks to speed up the runtime.
Please check
On Wed, Jun 22, 2016 at 09:49:41AM +0200, Peter Zijlstra wrote:
> On Wed, Jun 22, 2016 at 09:16:01AM +0200, Peter Zijlstra wrote:
> > WTF a benchmark needs that crap is beyond me, but whatever, I have
> > numbers.
>
> Oh, shaft me harder, its XML shite :/ How is a sane person ever going to
> get
On Wed, Jun 22, 2016 at 09:49:41AM +0200, Peter Zijlstra wrote:
> On Wed, Jun 22, 2016 at 09:16:01AM +0200, Peter Zijlstra wrote:
> > WTF a benchmark needs that crap is beyond me, but whatever, I have
> > numbers.
>
> Oh, shaft me harder, its XML shite :/ How is a sane person ever going to
> get
On Wed, Jun 22, 2016 at 09:16:01AM +0200, Peter Zijlstra wrote:
> WTF a benchmark needs that crap is beyond me, but whatever, I have
> numbers.
Oh, shaft me harder, its XML shite :/ How is a sane person ever going to
get numbers out.
I'm >.< close to giving up on this site and declaring the
On Wed, Jun 22, 2016 at 09:16:01AM +0200, Peter Zijlstra wrote:
> WTF a benchmark needs that crap is beyond me, but whatever, I have
> numbers.
Oh, shaft me harder, its XML shite :/ How is a sane person ever going to
get numbers out.
I'm >.< close to giving up on this site and declaring the
Could it be related to this:
https://www.phoronix.com/scan.php?page=news_item=P-State-Possible-4.6-Regression
On Thu, 16 Jun 2016 18:40:01 +0200
Jirka Hladky wrote:
> Hello,
>
> we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
> benchmarks starting from
Could it be related to this:
https://www.phoronix.com/scan.php?page=news_item=P-State-Possible-4.6-Regression
On Thu, 16 Jun 2016 18:40:01 +0200
Jirka Hladky wrote:
> Hello,
>
> we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
> benchmarks starting from 4.7.0-0.rc0 kernel
On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote:
> > > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
> > Blergh, of course I don't have those.. :/
>
> SPECjvm2008 is publicly available.
> https://www.spec.org/download.html
Urgh, I _so_ hate java.
Why does it have
On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote:
> > > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
> > Blergh, of course I don't have those.. :/
>
> SPECjvm2008 is publicly available.
> https://www.spec.org/download.html
Urgh, I _so_ hate java.
Why does it have
Hi Peter,
I have an update for this performance issue. I have tested several
kernels, I'm not at the parent of
2159197d6677 sched/core: Enable increased load resolution on 64-bit kernels
and I still see the performance regression for multithreaded workloads.
There are only 27 commits
Hi Peter,
I have an update for this performance issue. I have tested several
kernels, I'm not at the parent of
2159197d6677 sched/core: Enable increased load resolution on 64-bit kernels
and I still see the performance regression for multithreaded workloads.
There are only 27 commits
> > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
> Blergh, of course I don't have those.. :/
SPECjvm2008 is publicly available.
https://www.spec.org/download.html
We will prepare a reproducer and attach it to the BZ.
> What kind of config and userspace setup? Do you run this
> > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
> Blergh, of course I don't have those.. :/
SPECjvm2008 is publicly available.
https://www.spec.org/download.html
We will prepare a reproducer and attach it to the BZ.
> What kind of config and userspace setup? Do you run this
On Thu, Jun 16, 2016 at 06:38:50PM +0200, Jirka Hladky wrote:
> Hello,
>
> we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
Blergh, of course I don't have those.. :/
> benchmarks starting from 4.7.0-0.rc0 kernel compared to 4.6 kernel.
>
> We have tested kernels 4.7.0-0.rc1 and
On Thu, Jun 16, 2016 at 06:38:50PM +0200, Jirka Hladky wrote:
> Hello,
>
> we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
Blergh, of course I don't have those.. :/
> benchmarks starting from 4.7.0-0.rc0 kernel compared to 4.6 kernel.
>
> We have tested kernels 4.7.0-0.rc1 and
Hello,
we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
benchmarks starting from 4.7.0-0.rc0 kernel compared to 4.6 kernel.
We have tested kernels 4.7.0-0.rc1 and 4.7.0-0.rc3 and these are as
well affected.
We have observed the drop on variety of different x86_64 servers with
Hello,
we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008
benchmarks starting from 4.7.0-0.rc0 kernel compared to 4.6 kernel.
We have tested kernels 4.7.0-0.rc1 and 4.7.0-0.rc3 and these are as
well affected.
We have observed the drop on variety of different x86_64 servers with
68 matches
Mail list logo