4.13..4.14 scheduling overhead regression (bisected - b956575bed91)

4.13..4.14 scheduling overhead regression (bisected - b956575bed91)

[Mike Galbraith]

Greetings,

While dusting off regression testing trees, I noticed a substantial
pipe-test dent at 4.14, and bisected it to b956575bed91.  Log below.

skew_tick=1 audit=0 nodelayacct cgroup_disable=memory nopti nospectre_v2 nospec_store_bypass_disable
gov performance
taskset 0xc pipe-test 1

4.4.134         2.125751 usecs/loop -- avg 2.138286 935.3 KHz
4.5.7           2.111431 usecs/loop -- avg 2.141415 934.0 KHz
4.6.7           2.060672 usecs/loop -- avg 2.059993 970.9 KHz
4.7.10          2.086366 usecs/loop -- avg 2.090943 956.5 KHz
4.8.17          2.008318 usecs/loop -- avg 2.005780 997.1 KHz + ~2.00-ish   1.000
4.9.104         1.989143 usecs/loop -- avg 2.010945 994.6 KHz
4.10.17         2.010789 usecs/loop -- avg 2.006868 996.6 KHz
4.11.12         2.032123 usecs/loop -- avg 2.037766 981.5 KHz - ~2.04-ish   1.015   1.000
4.12.14         2.055745 usecs/loop -- avg 2.065894 968.1 KHz
4.13.16         2.024978 usecs/loop -- avg 2.045250 977.9 KHz
4.14.47         2.234518 usecs/loop -- avg 2.227716 897.8 KHz -- >2.22      1.110   1.093   1.000
4.15.18         2.287815 usecs/loop -- avg 2.295858 871.1 KHz --- >2.28     1.144   1.126   1.030
4.16.13         2.286036 usecs/loop -- avg 2.279057 877.6 KHz
4.17.0.g88a8676 2.288231 usecs/loop -- avg 2.288917 873.8 KHz

b956575bed91ecfb136a8300742ecbbf451471ab is the first bad commit
commit b956575bed91ecfb136a8300742ecbbf451471ab
Author: Andy Lutomirski <luto@kernel.org>
Date:   Mon Oct 9 09:50:49 2017 -0700

    x86/mm: Flush more aggressively in lazy TLB mode
    
git bisect start
# good: [569dbb88e80deb68974ef6fdd6a13edb9d686261] Linux 4.13
git bisect good 569dbb88e80deb68974ef6fdd6a13edb9d686261
# bad: [57a3ca7835962109d94533465a75e8c716b26845] Linux 4.14.47
git bisect bad 57a3ca7835962109d94533465a75e8c716b26845
# good: [fbf4432ff71b7a25bef993a5312906946d27f446] Merge branch 'akpm' (patches from Andrew)
git bisect good fbf4432ff71b7a25bef993a5312906946d27f446
# bad: [3fefc31843cfe2b5f072efe11ed9ccaf6a7a5092] Merge tag 'pm-final-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 3fefc31843cfe2b5f072efe11ed9ccaf6a7a5092
# good: [8d93c7a4315711ea0f7a95ca353a89c4ed0763fb] Merge tag 'pci-v4.14-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
git bisect good 8d93c7a4315711ea0f7a95ca353a89c4ed0763fb
# good: [0f380715e51f5ff418cfccb4cd0d4fe4c48c3241] Merge tag 'sound-4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good 0f380715e51f5ff418cfccb4cd0d4fe4c48c3241
# bad: [e5f468b3f23313994c5e6c356135f9b0d76bcb94] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect bad e5f468b3f23313994c5e6c356135f9b0d76bcb94
# good: [3d7882769b5dc929690f96e0c318c29b97f51018] Merge tag 'devprop-4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect good 3d7882769b5dc929690f96e0c318c29b97f51018
# bad: [ae7df8f985f1b0445366ae6f6324cd08a218526e] Merge tag 'char-misc-4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
git bisect bad ae7df8f985f1b0445366ae6f6324cd08a218526e
# good: [be1f16ba35d97aff4d85c0daba0a02da51b7c83c] Merge branch '4.14-fixes' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
git bisect good be1f16ba35d97aff4d85c0daba0a02da51b7c83c
# good: [a339b351304d5e6b02c7cf8eed895d181e64bce0] Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good a339b351304d5e6b02c7cf8eed895d181e64bce0
# bad: [7a23c5abb930cefcef85df6dc0c8fb3e8961980c] Merge tag 'dmaengine-fix-4.14-rc5' of git://git.infradead.org/users/vkoul/slave-dma
git bisect bad 7a23c5abb930cefcef85df6dc0c8fb3e8961980c
# good: [ab7ff471aa5db670197070760f022622793da7e5] x86/hyperv: Fix hypercalls with extended CPU ranges for TLB flushing
git bisect good ab7ff471aa5db670197070760f022622793da7e5
# bad: [1f161f67a272cc4f29f27934dd3f74cb657eb5c4] x86/microcode: Do the family check first
git bisect bad 1f161f67a272cc4f29f27934dd3f74cb657eb5c4
# good: [cc6afe2240298049585e86b1ade85efc8a7f225d] x86/apic: Silence "FW_BUG TSC_DEADLINE disabled due to Errata" on hypervisors
git bisect good cc6afe2240298049585e86b1ade85efc8a7f225d
# bad: [b956575bed91ecfb136a8300742ecbbf451471ab] x86/mm: Flush more aggressively in lazy TLB mode
git bisect bad b956575bed91ecfb136a8300742ecbbf451471ab
# good: [616dd5872e52493863b0202632703eebd51243dc] x86/apic: Update TSC_DEADLINE quirk with additional SKX stepping
git bisect good 616dd5872e52493863b0202632703eebd51243dc
# first bad commit: [b956575bed91ecfb136a8300742ecbbf451471ab] x86/mm: Flush more aggressively in lazy TLB mode

Re: 4.13..4.14 scheduling overhead regression (bisected - b956575bed91)

[Peter Zijlstra]

On Fri, Jun 01, 2018 at 02:57:53PM +0200, Mike Galbraith wrote:
> b956575bed91ecfb136a8300742ecbbf451471ab is the first bad commit
> commit b956575bed91ecfb136a8300742ecbbf451471ab
> Author: Andy Lutomirski <luto@kernel.org>
> Date:   Mon Oct 9 09:50:49 2017 -0700
> 
>     x86/mm: Flush more aggressively in lazy TLB mode

Oh boy... Maybe we should start looking at that optimization Andy
mentioned.

IIRC all page freeing does indeed go through tlb_remove_page(), it
shouldn't be too hard to make that work.

Re: 4.13..4.14 scheduling overhead regression (bisected - b956575bed91)

[Andy Lutomirski]

On Fri, Jun 1, 2018 at 6:21 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Jun 01, 2018 at 02:57:53PM +0200, Mike Galbraith wrote:
> > b956575bed91ecfb136a8300742ecbbf451471ab is the first bad commit
> > commit b956575bed91ecfb136a8300742ecbbf451471ab
> > Author: Andy Lutomirski <luto@kernel.org>
> > Date:   Mon Oct 9 09:50:49 2017 -0700
> >
> >     x86/mm: Flush more aggressively in lazy TLB mode
>
> Oh boy... Maybe we should start looking at that optimization Andy
> mentioned.

Jolly.

>
> IIRC all page freeing does indeed go through tlb_remove_page(), it
> shouldn't be too hard to make that work.

Before we go too far down this rabbit hole, let's figure out what's
actually going on.  Mike, does your system have PCID?  If it does,
then my proposed optimization wouldn't do anything.

Can you try inverting the return value of
tlb_defer_switch_to_init_mm() and seeing if the result changes?

Re: 4.13..4.14 scheduling overhead regression (bisected - b956575bed91)

[Rik van Riel]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Fri, 2018-06-01 at 15:20 +0200, Peter Zijlstra wrote:
> On Fri, Jun 01, 2018 at 02:57:53PM +0200, Mike Galbraith wrote:
> > b956575bed91ecfb136a8300742ecbbf451471ab is the first bad commit
> > commit b956575bed91ecfb136a8300742ecbbf451471ab
> > Author: Andy Lutomirski <luto@kernel.org>
> > Date:   Mon Oct 9 09:50:49 2017 -0700
> > 
> >     x86/mm: Flush more aggressively in lazy TLB mode
> 
> Oh boy... Maybe we should start looking at that optimization Andy
> mentioned.
> 
> IIRC all page freeing does indeed go through tlb_remove_page(), it
> shouldn't be too hard to make that work.

Page freeing does. However, page table freeing
does not, and might need to be done in a different
way.

I wonder how expensive/effective it would be to free
page tables with RCU, and have the RCU code flush the
TLB if it notices the ctx_id is wrong?

Also, I need to go find Andy's optimization, and
see how it works :)

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: 4.13..4.14 scheduling overhead regression (bisected - b956575bed91)

[Peter Zijlstra]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Fri, Jun 01, 2018 at 02:56:29PM -0400, Rik van Riel wrote:

> > IIRC all page freeing does indeed go through tlb_remove_page(), it
> > shouldn't be too hard to make that work.
> 
> Page freeing does. However, page table freeing
> does not, and might need to be done in a different
> way.

We have tlb_remove_table() for those. And that had better work otherwise
the whole 'RCU'-freed page table mess is broken :-)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]