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 sched/core, to pick up fixes before applying new changes 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? Thanks a lot! Jirka On Wed, Jun 22, 2016 at 2:46 PM, Jirka Hladky <jhla...@redhat.com> wrote: > 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 > load resolution on 64-bit kernels > > git bisect start > git bisect good 64b7aad > git bisect bad 2159197 > Bisecting: 1 revision left to test after this (roughly 1 step) > [eb58075149b7f0300ff19142e6245fe75db2a081] sched/core: Introduce > 'struct rq_flags' > > I should have results pretty soon. > > Jirka > > > On Wed, Jun 22, 2016 at 2:37 PM, Jirka Hladky <jhla...@redhat.com> wrote: >> Hi Peter, >> >> crap - I have done bisecting manually (not using git bisect) and I >> have probably done some mistake. >> >> Commits (git checkout <commit>) for which I got BAD results: >> >> 2159197d66770ec01f75c93fb11dc66df81fd45b >> 6ecdd74962f246dfe8750b7bea481a1c0816315d >> >> Commits (git checkout <commit>) for which I got GOOD results: >> 21e96f88776deead303ecd30a17d1d7c2a1776e3 >> 64b7aad5798478ffff52e110878ccaae4c3aaa34 >> e7904a28f5331c21d17af638cb477c83662e3cb6 >> >> I will try to use git bisect now. >>  >> Jirka >> >> On Wed, Jun 22, 2016 at 1:12 PM, Peter Zijlstra <pet...@infradead.org> wrote: >>> 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 <yuyang...@intel.com> >>>> Date: Tue Apr 5 12:12:26 2016 +0800 >>>> >>>> sched/fair: Generalize the load/util averages resolution definition >>>> ================================================= >>>> >>>> Could you please have a look? >>> >>> That patch looks like a NO-OP to me. >>> >>> In any case, the good news it that I can run the benchmark, the bad news >>> is that the patch you fingered doesn't appear to be it. >>> >>> >>> v4.60: >>> ./4.6.0/2016-Jun-22_11h11m07s.log:Score on xml.transform: 2007.18 ops/m >>> ./4.6.0/2016-Jun-22_11h11m07s.log:Score on xml.validation: 2999.44 ops/m >>> >>> tip/master: >>> ./4.7.0-rc4-00345-gf6e78bb/2016-Jun-22_11h30m27s.log:Score on >>> xml.transform: 1283.14 ops/m >>> ./4.7.0-rc4-00345-gf6e78bb/2016-Jun-22_11h30m27s.log:Score on >>> xml.validation: 2008.62 ops/m >>> >>> patch^1 >>> ./4.6.0-rc5-00034-g2159197/2016-Jun-22_12h38m50s.log:Score on >>> xml.transform: 1196.18 ops/m >>> ./4.6.0-rc5-00034-g2159197/2016-Jun-22_12h38m50s.log:Score on >>> xml.validation: 2055.11 ops/m >>> >>> patch^1 + patch >>> ./4.6.0-rc5-00034-g2159197-dirty/2016-Jun-22_12h55m43s.log:Score on >>> xml.transform: 1294.59 ops/m >>> ./4.6.0-rc5-00034-g2159197-dirty/2016-Jun-22_12h55m43s.log:Score on >>> xml.validation: 2140.02 ops/m >>> >>>
