summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorVishal Moola (Oracle) <vishal.moola@gmail.com>2025-10-21 22:44:56 +0300
committerAndrew Morton <akpm@linux-foundation.org>2025-11-17 04:28:15 +0300
commita0615780439938e8e61343f1f92a4c54a71dc6a5 (patch)
tree52bc877a7737b271bb4316c5b25222440a572dea /include
parent645a3c4243473d5c8b780927d2cc573e3da5a20c (diff)
downloadlinux-a0615780439938e8e61343f1f92a4c54a71dc6a5.tar.xz
mm/vmalloc: request large order pages from buddy allocator
Sometimes, vm_area_alloc_pages() will want many pages from the buddy allocator. Rather than making requests to the buddy allocator for at most 100 pages at a time, we can eagerly request large order pages a smaller number of times. We still split the large order pages down to order-0 as the rest of the vmalloc code (and some callers) depend on it. We still defer to the bulk allocator and fallback path in case of order-0 pages or failure. Running 1000 iterations of allocations on a small 4GB system finds: 1000 2mb allocations: [Baseline] [This patch] real 46.310s real 0m34.582 user 0.001s user 0.006s sys 46.058s sys 0m34.365s 10000 200kb allocations: [Baseline] [This patch] real 56.104s real 0m43.696 user 0.001s user 0.003s sys 55.375s sys 0m42.995s Link: https://lkml.kernel.org/r/20251021194455.33351-2-vishal.moola@gmail.com Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com> Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions