Re: [SCHEDULER] Performance drop in 4.19 compared to 4.18 kernel

[Jirka Hladky]

Resending in the plain text mode.

> I'm travelling at the moment but when I get back, I'll see what's in the
> tip tree with respect to Srikar's patches and then rebase the fast-migration
> patches on top and reconfirm they still behave as expected. Assuming
> they do, I'll resend them.


Sounds great, thank you!

If you want me to retest the rebased patch set, just let me know, we
would be more than happy to run the tests on our side.
ï
Jirka

On Mon, Sep 17, 2018 at 3:06 PM, Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Sep 14, 2018 at 04:50:20PM +0200, Jirka Hladky wrote:
>> Hi Peter and Srikar,
>>
>> > I have bounced the 5 patches to you, (one of the 6 has not been applied by
>> > Peter) so I have skipped that.
>> > They can also be fetched from
>> > http://lore.kernel.org/lkml/1533276841-16341-1-git-send-email-srikar@xxxxxxxxxxxxxxxxxx
>>
>> I'm sorry for the delay, we have finally the results for the above
>> kernel. The performance results look good compared to 4.19 vanilla and
>> are about the same as Mel's sched-numa-fast-crossnode-v1r12 patch set
>> for 4.18:
>>
>> Compared to kernel-4.19.0-0.rc1.1
>>
>>   * Improvement upto 20% for SPECjbb2005, SPECjvm2008 benchmarks
>>   * Improvement upto 50% for stream benchmark
>>   * Improvement upto 100% for the NAS benchmark (sp_C subtest, 8
>> threads on 4 NUMA system with 4x E5-4610 v2 @ 2.30GHz, 64 cores in
>> total)
>>
>> When I compare it against Mel's patchset
>> (git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git
>> sched-numa-fast-crossnode-v1r12)
>>
>>   * Mel's kernel is about 15% faster for stream benchmarks
>>   * The other benchmarks show very similar results with both kernels
>>
>> Mel's patchset eliminates NUMA migration rate limits, this is
>> presumbly the reason for the good stream results.
>>
>> Do you have any update when the current patchset could be merged into
>> the upstream kernel?
>>
>
> I'm travelling at the moment but when I get back, I'll see what's in the
> tip tree with respect to Srikar's patches and then rebase the fast-migration
> patches on top and reconfirm they still behave as expected. Assuming
> they do, I'll resend them.