> Maybe 305c1fac3225dfa7eeb89bfe91b7335a6edd5172. That introduces a weird > condition in terms of idle CPU handling that has been problematic. We will try that, thanks! > I would suggest contacting Srikar directly. I will do that right away. Whom should I put on Cc? Just you and linux-kernel@xxxxxxxxxxxxxxx ? Should I put Ingo and Peter on Cc as well? $scripts/get_maintainer.pl -f kernel/sched Ingo Molnar <mingo@xxxxxxxxxx> (maintainer:SCHEDULER) Peter Zijlstra <peterz@xxxxxxxxxxxxx> (maintainer:SCHEDULER) linux-kernel@xxxxxxxxxxxxxxx (open list:SCHEDULER) Jirka On Thu, Sep 6, 2018 at 2:58 PM, Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Sep 06, 2018 at 10:16:28AM +0200, Jirka Hladky wrote: >> Hi Mel, >> >> we have results with 2d4056fafa196e1ab4e7161bae4df76f9602d56d reverted. >> >> * Compared to 4.18, there is still performance regression - >> especially with NAS (sp_C_x subtest) and SPECjvm2008. On 4 NUMA >> systems, regression is around 10-15% >> * Compared to 4.19rc1 there is a clear gain across all benchmarks around 20% >> > > Ok. > >> While reverting 2d4056fafa196e1ab4e7161bae4df76f9602d56d has helped a >> lot there is another issue as well. Could you please recommend some >> commit prior to 2d4056fafa196e1ab4e7161bae4df76f9602d56d to try? >> > > Maybe 305c1fac3225dfa7eeb89bfe91b7335a6edd5172. That introduces a weird > condition in terms of idle CPU handling that has been problematic. > >> Regarding the current results, how do we proceed? Could you please >> contact Srikar and ask for the advice or should we contact him >> directly? >> > > I would suggest contacting Srikar directly. While I'm working on a > series that touches off some similar areas, there is no guarantee it'll > be a success as I'm not primarily upstream focused at the moment. > > Restarting the thread would also end up with a much more sensible cc > list. > > -- > Mel Gorman > SUSE Labs
