diff options
| author | Chen Wandun <[email protected]> | 2021-11-05 20:39:53 +0000 |
|---|---|---|
| committer | Linus Torvalds <[email protected]> | 2021-11-06 20:30:37 +0000 |
| commit | c00b6b9610991c042ff4c3153daaa3ea8522c210 (patch) | |
| tree | e3e4399ba2a74e6e4702a98e525b6f62822b8c3a /lib/test_vmalloc.c | |
| parent | mm/vmalloc: be more explicit about supported gfp flags (diff) | |
| download | kernel-c00b6b9610991c042ff4c3153daaa3ea8522c210.tar.gz kernel-c00b6b9610991c042ff4c3153daaa3ea8522c210.zip | |
mm/vmalloc: introduce alloc_pages_bulk_array_mempolicy to accelerate memory allocation
Commit ffb29b1c255a ("mm/vmalloc: fix numa spreading for large hash
tables") can cause significant performance regressions in some
situations as Andrew mentioned in [1]. The main situation is vmalloc,
vmalloc will allocate pages with NUMA_NO_NODE by default, that will
result in alloc page one by one;
In order to solve this, __alloc_pages_bulk and mempolicy should be
considered at the same time.
1) If node is specified in memory allocation request, it will alloc all
pages by __alloc_pages_bulk.
2) If interleaving allocate memory, it will cauculate how many pages
should be allocated in each node, and use __alloc_pages_bulk to alloc
pages in each node.
[1]: https://lore.kernel.org/lkml/CALvZod4G3SzP3kWxQYn0fj+VgG-G3yWXz=gz17+3N57ru1iajw@mail.gmail.com/t/#m750c8e3231206134293b089feaa090590afa0f60
[[email protected]: coding style fixes]
[[email protected]: make two functions static]
[[email protected]: fix CONFIG_NUMA=n build]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Chen Wandun <[email protected]>
Reviewed-by: Uladzislau Rezki (Sony) <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Shakeel Butt <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Kefeng Wang <[email protected]>
Cc: Hanjun Guo <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'lib/test_vmalloc.c')
0 files changed, 0 insertions, 0 deletions
