linux-kernel - Re: [BUG] numa spreading of large hash tables no longer a thing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 25 Sep 2021 08:54:46 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        Nicholas Piggin <npiggin@...il.com>
Subject: Re: [BUG] numa spreading of large hash tables no longer a thing

On Fri, Sep 24, 2021 at 12:55 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> Hi Andrew and mm experts
>
> It seems recent kernels lost the NUMA spreading of large hash tables
> allocated at boot time.
>
> Does it ring a bell, was it intentional ?
> Thanks

I did a bisection and it went back to the following commit [1]

Probably the removal of

-               if (node == NUMA_NO_NODE)
-                       page = alloc_page(gfp_mask);
-               else
-                       page = alloc_pages_node(node, gfp_mask, 0);

had something to do with the regression.

Things got a little bit more complicated after the introduction of
bulk allocations.

[1]
commit 121e6f3258fe393e22c36f61a319be8a4f2c05ae
Author: Nicholas Piggin <npiggin@...il.com>
Date:   Thu Apr 29 22:58:49 2021 -0700

    mm/vmalloc: hugepage vmalloc mappings

    Support huge page vmalloc mappings.  Config option HAVE_ARCH_HUGE_VMALLOC
    enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
    supports PMD sized vmap mappings.

    vmalloc will attempt to allocate PMD-sized pages if allocating PMD size or
    larger, and fall back to small pages if that was unsuccessful.

    Architectures must ensure that any arch specific vmalloc allocations that
    require PAGE_SIZE mappings (e.g., module allocations vs strict module rwx)
    use the VM_NOHUGE flag to inhibit larger mappings.

    This can result in more internal fragmentation and memory overhead for a
    given allocation, an option nohugevmalloc is added to disable at boot.

    [colin.king@...onical.com: fix read of uninitialized pointer area]
      Link: https://lkml.kernel.org/r/20210318155955.18220-1-colin.king@canonical.com

    Link: https://lkml.kernel.org/r/20210317062402.533919-14-npiggin@gmail.com
    Signed-off-by: Nicholas Piggin <npiggin@...il.com>
    Cc: Borislav Petkov <bp@...en8.de>
    Cc: Catalin Marinas <catalin.marinas@....com>
    Cc: Christoph Hellwig <hch@....de>
    Cc: Ding Tianhong <dingtianhong@...wei.com>
    Cc: "H. Peter Anvin" <hpa@...or.com>
    Cc: Ingo Molnar <mingo@...hat.com>
    Cc: Miaohe Lin <linmiaohe@...wei.com>
    Cc: Michael Ellerman <mpe@...erman.id.au>
    Cc: Russell King <linux@...linux.org.uk>
    Cc: Thomas Gleixner <tglx@...utronix.de>
    Cc: Uladzislau Rezki (Sony) <urezki@...il.com>
    Cc: Will Deacon <will@...nel.org>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

 arch/Kconfig            |  11 +++
 include/linux/vmalloc.h |  21 +++++
 mm/page_alloc.c         |   5 +-
 mm/vmalloc.c            | 220 +++++++++++++++++++++++++++++++++++++-----------
 4 files changed, 209 insertions(+), 48 deletions(-)

>
> Old behavior
> otrv5:~# grep alloc_large_system_hash /proc/vmallocinfo
> 0x000000006381d67a-0x000000009bc8465a   12288
> alloc_large_system_hash+0xf1/0x290 pages=2 vmalloc N0=1 N1=1
> 0x000000009bc8465a-0x00000000b70c6dfc   12288
> alloc_large_system_hash+0xf1/0x290 pages=2 vmalloc N0=1 N1=1
> 0x00000000b70c6dfc-0x00000000ab13330f   12288
> alloc_large_system_hash+0xf1/0x290 pages=2 vmalloc N0=1 N1=1
> 0x000000008685d551-0x000000009ce0c789   12288
> alloc_large_system_hash+0xf1/0x290 pages=2 vmalloc N0=1 N1=1
> 0x000000004d87acca-0x00000000781b44e4  266240
> alloc_large_system_hash+0xf1/0x290 pages=64 vmalloc N0=32 N1=32
> 0x00000000dea0f2d2-0x00000000909e9fb3 268439552
> alloc_large_system_hash+0xf1/0x290 pages=65536 vmalloc vpages N0=32768
> N1=32768
> 0x00000000909e9fb3-0x00000000d23f4353  528384
> alloc_large_system_hash+0xf1/0x290 pages=128 vmalloc N0=64 N1=64
> 0x00000000d23f4353-0x000000003913e8bc 134221824
> alloc_large_system_hash+0xf1/0x290 pages=32768 vmalloc vpages N0=16384
> N1=16384
> 0x000000003913e8bc-0x000000007a60bcd6 4198400
> alloc_large_system_hash+0xf1/0x290 pages=1024 vmalloc vpages N0=512
> N1=512
> 0x000000007a60bcd6-0x0000000001bc8bf9 4198400
> alloc_large_system_hash+0xf1/0x290 pages=1024 vmalloc vpages N0=512
> N1=512
> 0x0000000001bc8bf9-0x0000000022629b89 4198400
> alloc_large_system_hash+0xf1/0x290 pages=1024 vmalloc vpages N0=512
> N1=512
> 0x0000000022629b89-0x0000000027d1b0a7 1052672
> alloc_large_system_hash+0xf1/0x290 pages=256 vmalloc N0=128 N1=128
> 0x0000000027d1b0a7-0x0000000027310068 4198400
> alloc_large_system_hash+0xf1/0x290 pages=1024 vmalloc vpages N0=512
> N1=512
> 0x0000000027310068-0x00000000a845050a 1052672
> alloc_large_system_hash+0xf1/0x290 pages=256 vmalloc N0=128 N1=128
> 0x00000000a845050a-0x0000000028b8c1bc 2101248
> alloc_large_system_hash+0xf1/0x290 pages=512 vmalloc N0=256 N1=256
> 0x0000000028b8c1bc-0x000000002aff2d3d 2101248
> alloc_large_system_hash+0xf1/0x290 pages=512 vmalloc N0=256 N1=256
>
> New behavior
> otrv6:~# grep alloc_large_system_hash /proc/vmallocinfo
> 0x00000000de22dded-0x000000006574cf88   12288
> alloc_large_system_hash+0x18c/0x272 pages=2 vmalloc N0=2
> 0x000000006574cf88-0x00000000bc158a1d   12288
> alloc_large_system_hash+0x18c/0x272 pages=2 vmalloc N0=2
> 0x00000000afa304a2-0x0000000009981fb8   12288
> alloc_large_system_hash+0x18c/0x272 pages=2 vmalloc N0=2
> 0x00000000e3ab78c1-0x00000000ddbeadf2  528384
> alloc_large_system_hash+0x18c/0x272 pages=128 vmalloc N0=128
> 0x0000000000cce551-0x0000000022096e73   12288
> alloc_large_system_hash+0x18c/0x272 pages=2 vmalloc N0=2
> 0x0000000072a43217-0x00000000cf0c05f7  266240
> alloc_large_system_hash+0x18c/0x272 pages=64 vmalloc N0=64
> 0x000000003f85e695-0x0000000042154f88 268439552
> alloc_large_system_hash+0x18c/0x272 pages=65536 vmalloc vpages
> N0=65536
> 0x0000000042154f88-0x0000000066fcdca2 134221824
> alloc_large_system_hash+0x18c/0x272 pages=32768 vmalloc vpages
> N0=32768
> 0x0000000066fcdca2-0x000000004074129c 4198400
> alloc_large_system_hash+0x18c/0x272 pages=1024 vmalloc vpages N0=1024
> 0x000000004074129c-0x00000000ca32b7f9 4198400
> alloc_large_system_hash+0x18c/0x272 pages=1024 vmalloc vpages N0=1024
> 0x00000000ca32b7f9-0x00000000a56b8117 4198400
> alloc_large_system_hash+0x18c/0x272 pages=1024 vmalloc vpages N0=1024
> 0x00000000a56b8117-0x0000000089e9e39e 2101248
> alloc_large_system_hash+0x18c/0x272 pages=512 vmalloc N0=512
> 0x0000000089e9e39e-0x0000000090a80b5a 1052672
> alloc_large_system_hash+0x18c/0x272 pages=256 vmalloc N0=256
> 0x0000000090a80b5a-0x00000000e84776cb 4198400
> alloc_large_system_hash+0x18c/0x272 pages=1024 vmalloc vpages N0=1024
> 0x00000000e84776cb-0x000000006cfc05bf 1052672
> alloc_large_system_hash+0x18c/0x272 pages=256 vmalloc N0=256
> 0x000000006cfc05bf-0x00000000f6ce3623 1576960
> alloc_large_system_hash+0x18c/0x272 pages=384 vmalloc N0=384
> 0x00000000f6ce3623-0x0000000002737823 2101248
> alloc_large_system_hash+0x18c/0x272 pages=512 vmalloc N0=512
> 0x0000000002737823-0x00000000d4e74269 2101248
> alloc_large_system_hash+0x18c/0x272 pages=512 vmalloc N0=512