linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@google.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	 linux-mm <linux-mm@kvack.org>
Subject: [BUG] numa spreading of large hash tables no longer a thing
Date: Fri, 24 Sep 2021 12:55:18 -0700	[thread overview]
Message-ID: <CANn89iL6AAyWhfxdHO+jaT075iOa3XcYn9k6JJc7JR2XYn6k_Q@mail.gmail.com> (raw)

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

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


             reply	other threads:[~2021-09-24 19:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-24 19:55 Eric Dumazet [this message]
2021-09-25 15:54 ` [BUG] numa spreading of large hash tables no longer a thing Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANn89iL6AAyWhfxdHO+jaT075iOa3XcYn9k6JJc7JR2XYn6k_Q@mail.gmail.com \
    --to=edumazet@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).