From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4443DFC0A for ; Sat, 13 Jun 2026 17:21:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781371311; cv=none; b=IZ9hbDvyCgHrIb+7N+hGhHA3W+I/EXefkB6O3Hp365WVbyCF4hG1iVSYZU296KxUCoCjSRHdvsk0UP2KaSoVA4CxcZqhOUFAO0L0Gx8fi+gj1a3L52RKOYFB+AbB1ir5siBEzc+ZV6h06QHQ/6h87f49bA6SbS02I3DzgR8ssG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781371311; c=relaxed/simple; bh=PsqiD8G6HiZiANmDP/iDjGIPvGoKXcMiDUmCdx9BhDA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qXo4Y0lH7Z0YGsalnyoJJMv+Z5FZa7QrDzgiJTq4NBBJRb13uYhuECXyGrrNoVgd2+MqeVFhnllwTEpztjGVSXAmpvIBn/U2yCukPMOBi1k8jZrgM/sn7pPV+aEvhixnsaLqIOnC23RosmyKb7MDKh4olQ8VZ/A6ea5H/KUXdeI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=F3d3zfgV; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Y5FKaIlU; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="F3d3zfgV"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Y5FKaIlU" Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65DFC84C3230490 for ; Sat, 13 Jun 2026 17:21:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= CEwkWdeK2JOxz6CkWOPVdEpzOJip0EPBtxLmX7NxFto=; b=F3d3zfgVQWpLzqDb rVHYFKrrSxRwKj/qdAheSyaCiab4OUQWb9AmJytKD3J+LB2MSuXW61DmfyhWWjQW CKmSuBYXIsTMaCuJta5D/TNu7gIaHsh9A5GAuZ/gXS9zcqHIf9hlA1jCzoNRtgwF XDb/aaLKwthBrUC4viEg6Q5lQEbeFENAEkS5QY9hz3+FSxHIrO2tMQCRyXM4MuZv nnkelEy0BYA4jWhypdLJwcJFQJ4Mis0U+I6U6dJMWpa3vFkmEcv6xNI2ea4Acv/S RsFPtl9UlF192CxhabyjaVZVonAv+/T7imas3ScKscxTW8/NGozkJHK/zhVRH21L OmNUeQ== Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ery7u1mtg-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sat, 13 Jun 2026 17:21:48 +0000 (GMT) Received: by mail-pg1-f199.google.com with SMTP id 41be03b00d2f7-c85c530ddebso958727a12.1 for ; Sat, 13 Jun 2026 10:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781371308; x=1781976108; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=CEwkWdeK2JOxz6CkWOPVdEpzOJip0EPBtxLmX7NxFto=; b=Y5FKaIlUZ/NCXNffPi7p7nDvRqbeXboi7A+jMP0SZkKVwDjG44kyVVdG1sEFKmytvL 542WpkVU2+4FjkDTVTAsdGNlVgXqCAKAefmb2J9BbjvzTTVnUDuFaI5SQ5zpVbbfDTym Tnu31MmSJMcyWtij+QV1avoYuZaXrIWnmXlflGjtswxewWFbtgi72reil9pAw7cd4PU+ OHMZPPvjEMkakx0MX7knxorfvZkfdAxBSvcAkvy3cyZaF8hAQc6plZGR1it0ozOCaoAW JsrH1pxeoXzIzVjvrYC3c9YTjgfOdG/8x/faZYqfXMW/cq9e5vPJgAwEdF2RFa6M3RbA 34KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781371308; x=1781976108; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=CEwkWdeK2JOxz6CkWOPVdEpzOJip0EPBtxLmX7NxFto=; b=sdJYItX6vn01gUvUGmiM95Rde4zGNDDCp9LJ8yxE2c8ZV3bXxL1j4U8M0EAuC9bDt3 rvOSqElFU3bsKO3hvTjHXmyD0kSFs4FuE3J4iPQO7VWcrknydbIpMMLgk8Inmv3Ge0Bz S7EVToJStcNBQK21Duv1IoKeMgOIIH2raOzk/V0z3TmA5PGLIiWll6j9exwlHgzbGYHE EyuACqx0I6+DumzuRqmCGG6tdsMPt9cIFpUqLk7W7I4Y3NFYzoKCTkTnAyCZB4e4nEkp oqX1Z2mkk6TPLCdjlC9qhiKOCTW34MgAtIvbW+BKS2heIM5lEqyXj4AbwQ3vNA8JRG8d pvRg== X-Forwarded-Encrypted: i=1; AFNElJ8KCwJ3OUzuLeoa6FP2yVY8Romh00+gViVp2BszzWe8rxDSUOW7cuD1OvCtp48jrLtqB1/nmEjG3dEQ4sw=@vger.kernel.org X-Gm-Message-State: AOJu0Yzv3G9nTXeD0uWaqB03BtmVfjjM+sxmj0fn+5oPrZco53U4mYMr N4Jg/bnIdTLSleDRtnF6vDYehOu6GJ6iPx8Sdj2Ga1ceubZgJtktbddeLiyqczozagzrp6RdbDl O84MXUfiX5Mddl3p5p671f9NpDJTii2MbPlyT1/zeQ9Yje3vgCr+SQTQ2oL9pPcoe4dQ= X-Gm-Gg: Acq92OGkYV4sgbuLgN8Fy0yY3p12tWDJMbQjMs+cjCyOAx7RppmyqcGrS++uyGldnj8 qC7OO2cCWXUO2ZhBYT17/hmFVhpFjM8Idg4H2yDmW93i2iXq9bYZUFJ312SLCwYBGsUHpFfnSCF cBfSKxEg1ksPBitMTCmf1TtD1XgpbsG96+iGxQtrd/BBd+RKsUUKu5oVFSxVjDoD/ow9mZpYCi1 uCRam5JxByxCLGT3PhAUErwPmR8pA5zfd2AaeN6RaRng9SiZEebfAVzkiUYbxWdGWJJddA8HxQD YMIfBD9Ujo4N2q9duhgmCvad4oLQRg9cMsFImKzng0ABWYX60LBpwcFJQV28IpI1Q1xlwvoKV5u F2shVRH0ck+kERCny/wDbN84gwpFF25ZwAVDBJueaCKobyqBM18uTxw== X-Received: by 2002:a05:6a00:3996:b0:842:3be7:4d57 with SMTP id d2e1a72fcca58-8434ce31498mr7995843b3a.18.1781371307763; Sat, 13 Jun 2026 10:21:47 -0700 (PDT) X-Received: by 2002:a05:6a00:3996:b0:842:3be7:4d57 with SMTP id d2e1a72fcca58-8434ce31498mr7995808b3a.18.1781371307197; Sat, 13 Jun 2026 10:21:47 -0700 (PDT) Received: from hu-pranarya-hyd.qualcomm.com ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434accbec5sm5390913b3a.16.2026.06.13.10.21.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Jun 2026 10:21:46 -0700 (PDT) From: Pranjal Arya Date: Sat, 13 Jun 2026 22:49:52 +0530 Subject: [PATCH RFC 10/12] mm/vmalloc: per-CPU caching of free ranges from the maple_tree allocator Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260613-vmalloc_maple-v1-10-0aa740bb944b@oss.qualcomm.com> References: <20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com> In-Reply-To: <20260613-vmalloc_maple-v1-0-0aa740bb944b@oss.qualcomm.com> To: Andrew Morton , Uladzislau Rezki , "Liam R. Howlett" , Alice Ryhl , Andrew Ballance Cc: linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org, Lorenzo Stoakes , Pranjal Shrivastava , Will Deacon , Suzuki K Poulose , Neil Armstrong , Mostafa Saleh , Balbir Singh , Suren Baghdasaryan , Marco Elver , Dmitry Vyukov , Alexander Potapenko , Shuah Khan , Dev Jain , Brendan Jackman , Puranjay Mohan , Santosh Shukla , Wyes Karny , Pranjal Arya , Sudeep Holla X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1781371215; l=10345; i=pranjal.arya@oss.qualcomm.com; s=20260516; h=from:subject:message-id; bh=PsqiD8G6HiZiANmDP/iDjGIPvGoKXcMiDUmCdx9BhDA=; b=Rzw5Lud8MlSAcq9OrXE/82DTua23HOpREVjTa+P4bOWSQXGGH2GBYsa2/2zyORRZl+X2/MnQV Ju0LVd2eH8fBQb6oGLJiYWu3DKB8RDzJ/6N+2REGYcU7x9VGIQ29X4s X-Developer-Key: i=pranjal.arya@oss.qualcomm.com; a=ed25519; pk=ymtcTlccEIDsi3ErhpjIoZZHKdPBYWGWW0Lchs5MsbE= X-Authority-Analysis: v=2.4 cv=F8BnsKhN c=1 sm=1 tr=0 ts=6a2d91ac cx=c_pps a=Oh5Dbbf/trHjhBongsHeRQ==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=EUspDBNiAAAA:8 a=FUy_0n9OcN9IEB7T7O0A:9 a=QEXdDO2ut3YA:10 a=_Vgx9l1VpLgwpw_dHYaR:22 X-Proofpoint-GUID: XPz86AXHmqOUEw_pnu44Ztw1hS_GzuWf X-Proofpoint-ORIG-GUID: XPz86AXHmqOUEw_pnu44Ztw1hS_GzuWf X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjEzMDE4MCBTYWx0ZWRfX2esWVc8WVjuA 6M/K6LO246wcncx8HguZyhJLuNcgQJXmdory/Fm8dI9Vkl71jEgKqPvojWCexGp6aK4M7C2u5KP TsXNqbQMJa6cKVg1ShsrVHD7Aa8H5URKVIZtmy12cCHl4lpRNblp3+yl1WeKYh8WBuCXzTHpmT6 aI0NZ55sugI6EjhtnNDM2Bi9I2qUAK7sKh2KlXPcJgp69ZlJFMzwbAm3ieLYGbcpP+SAs/bbSQd suIVAqKuUJpal8/ewcX0LP/uGrgCczqwbzjTCZ9lPQZGXkWNTMEAcYzLJkCkWsGdYHLPH722rJB UBJGLJkJJa0nLyRnYR3+IfmJxEq1M3nsflaV4Sv4MjZhryhY8JBcQ2kwz7ZTahy59OWGAqjan5l F2ZDiaRikH3l4LwLzsap/g9KwVmjp8wkHrgxeBkYSv/rd8KbNzkS0/PX+QTfjEddLIBMzHFErhe aX4uIKhluGIEI5vTBUA== X-Proofpoint-Spam-Info: AW1haW4tMjYwNjEzMDE4MCBTYWx0ZWRfX5NVba4iks7bZ 48D9+lGGLivXWNF4BDgLj5o/reBKj5/6DYgjUP7HyYi8ItWDK/IKZ3DiUM+nP/Nvo2cydGXPzVL lD/BzMErn9FzKXkoudz6u7BtO33EBm0= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-13_03,2026-06-12_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 phishscore=0 impostorscore=0 spamscore=0 suspectscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606040000 definitions=main-2606130180 Now that the alloc path goes through the maple_tree-based gap finder (mas_empty_area), amortise the cost of visiting it for the most common shape of vmalloc call: short-lived, page-aligned, PAGE_SIZE-multiple allocations. Each CPU reserves a 64 MB chunk via __alloc_vmap_area -- the same maple-backed allocator the global path uses -- and dispenses page- aligned allocations from a bump pointer inside that chunk. Chunk reservation and drain are the only operations that touch the global allocator; per-allocation work stays entirely per-CPU. When a chunk's allocation count returns to zero and it is no longer the per-CPU current chunk, vmap_bump_unlink() releases the chunk's range back to the global allocator via occupied_mt_erase_range_locked -- the same maple primitive the consolidate-occupied-tree patch made authoritative. The chunk install path uses occupied_mt_store_range_locked symmetrically, so cache lifecycle is expressed entirely through the maple-tree's range primitives. Per-CPU access uses preempt_disable() rather than a spinlock; the chunk pointer is per-CPU and only mutated by its owner. The chunks list (vmap_bump_chunks) is gated by a single global spinlock that is taken only on chunk install/release, not on the fast path. Why this overlay sits on the maple_tree migration ================================================= The overlay relies on three primitives that maple_tree provides natively and that the augmented rb_tree allocator does not expose in a clean form: - Bare [base, limit) range reservation. The augmented rb_node carries a vmap_area-shaped subtree_max_size consulted by find_vmap_lowest_match. A chunk reservation has no associated vmap_area object, so it cannot be stored in the augmented tree without either synthesising a fake vmap_area per chunk or introducing a parallel range tracker with its own augmentation discipline. maple_tree stores [base, limit) ranges natively and the gap walker (mas_empty_area) returns the lowest free region in a single descent, sharing one primitive with the regular allocation path. - Sentinel range storage. occupied_vmap_area_mt records a reserved chunk as XA_ZERO_ENTRY over [base, limit), sharing one index with ordinary in-use vmap_area ranges. The augmented rb_tree has no equivalent of XA_ZERO_ENTRY: a chunk would have to live in a dedicated structure, doubling the alloc-side state surface. - RCU range traversal. vmap_chunk_lookup() must run lock-free so that cross-chunk vfree() does not take a global spinlock per free of a chunk-resident allocation. maple_tree supports RCU traversal as a property of the data structure; rb_tree-side equivalents (lib/rbtree_latch, hand-rolled grace-period accounting on top of rb_tree) impose write-side cost and would have to be added to vmalloc as new infrastructure. After the migration these three primitives are part of the allocator API; the overlay reuses mas_empty_area() for chunk refill, occupied_mt_store_range_locked() and occupied_mt_erase_range_locked() for chunk lifecycle, and maple-tree-friendly RCU for the chunk-list lookup. No parallel data structures are introduced. VMAP_BUMP_CHUNK_SIZE = 64 MB derivation ======================================= The chunk size is the smallest power-of-two value that satisfies three independent constraints: 1. Eligibility coverage. vmap_bump_eligible() requires size <= VMAP_BUMP_CHUNK_SIZE / 2 so that any single eligible allocation fits with room for alignment slack. The largest standard-range vmalloc() callers in tree are the module loader (modules can carry up to ~32 MB of text + RO data + RW data on architectures with full kernel module support) and BPF JIT buffers (capped near 4 MB). Setting CHUNK_SIZE = 64 MB keeps all of these on the bump fast path; halving the chunk to 32 MB would push module loads to the slow path. 2. Refill amortisation. The global vmalloc lock is taken once per chunk refill, paying for ~CHUNK_SIZE / avg_alloc_size bump allocations between lock acquisitions. At avg = 4 KB (a plausible lower bound for typical kernel vmalloc traffic), 64 MB amortises to ~16,000 fast-path allocations per global lock acquisition; at avg = 1 MB, ~64 per lock. Doubling the chunk size beyond 64 MB barely improves this ratio. 3. Address-space cost. Each CPU pins a chunk-sized reservation within the vmalloc range. On a 32-CPU server with the standard 128 GB x86_64 vmalloc range, 64 MB chunks reserve 32 * 64 MB = 2 GB = 1.6 % of the range. On arm64 with CONFIG_ARM64_VA_BITS=52 (256 PB vmalloc), the cost is negligible. Doubling to 128 MB pushes the x86_64 reservation to 3.2 %, which is still acceptable but starts to matter for workloads with high CPU counts. Per-chunk metadata associated with each chunk is sized as sizeof(struct vmap_area *) * (CHUNK_SIZE / PAGE_SIZE), which scales linearly with chunk size and stays at a constant 0.2 % overhead regardless of the chosen value. At 64 MB this is 128 KB per chunk. 64 MB is therefore the *minimum* chunk size that meets constraint (1) and (2) simultaneously; constraint (3) sets the upper bound and allows growing the chunk if module sizes grow in the future. The constant is exposed at the top of the bump-allocator code block so distributors can tune it for unusual configurations. Allocations that don't match the predicate (non-page-aligned, larger than half a chunk, fixed-VA, or with NUMA constraints) fall through to the existing __alloc_vmap_area path unchanged. Signed-off-by: Pranjal Arya --- mm/vmalloc.c | 107 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 463127d5ce58..65ee80eaf4bf 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2467,6 +2467,98 @@ static inline void setup_vmalloc_vm(struct vm_struct *vm, va->vm = vm; } +/* + * Per-CPU bump-allocator overlay. + * + * Each CPU reserves a contiguous chunk of vmalloc address space and + * dispenses page-aligned allocations via a bump pointer. The chunk's + * range is reserved through the global allocator once; individual + * allocations within the chunk avoid the global maple-tree work + * entirely. Each allocation still gets its own vmap_area struct and + * is inserted into the per-node busy.mt, so find_vmap_area() and + * vfree() continue to work unchanged. + * + * Recycling: chunks leak in this minimal form. With 16 MB chunks on a + * 128 GB vmalloc range, the address space supports thousands of chunks + * before exhaustion. A future iteration can add chunk recycling via a + * va->bump_chunk back-pointer + refcount; deferred to keep this hot + * path's struct vmap_area footprint at 48 B. + * + * Constraints: only the standard vmalloc range with align <= PAGE_SIZE + * and size <= VMAP_BUMP_CHUNK_SIZE/2 takes the bump path. Anything + * else falls through to the existing __alloc_vmap_area path. + */ +#define VMAP_BUMP_CHUNK_SIZE (64UL * 1024 * 1024) + +struct vmap_bump_chunk { + unsigned long base; + unsigned long limit; + unsigned long bump; +}; + +static DEFINE_PER_CPU(struct vmap_bump_chunk, vmap_bump); +static DEFINE_PER_CPU(spinlock_t, vmap_bump_lock); + +/* Try the per-CPU bump-allocator. Returns the chosen address or + * a negative IS_ERR_VALUE on miss; callers fall through to the + * regular path on miss. + */ +static unsigned long +vmap_bump_alloc(unsigned long size, unsigned long align, + unsigned long vstart, unsigned long vend) +{ + struct vmap_bump_chunk *chunk; + spinlock_t *lock; + unsigned long aligned, addr = -ENOENT; + + if (vstart != VMALLOC_START || vend != VMALLOC_END || + size == 0 || size > VMAP_BUMP_CHUNK_SIZE / 2 || + align > VMAP_BUMP_CHUNK_SIZE / 2) + return -EINVAL; + + lock = this_cpu_ptr(&vmap_bump_lock); + spin_lock(lock); + chunk = this_cpu_ptr(&vmap_bump); + if (chunk->base) { + aligned = ALIGN(chunk->bump, align); + if (aligned + size <= chunk->limit) { + chunk->bump = aligned + size; + addr = aligned; + } + } + spin_unlock(lock); + return addr; +} + +/* Refill this CPU's bump chunk. Reserves a fresh range from the + * global allocator. Old chunk's remaining space is leaked (the + * already-allocated VAs in it stay live; the unused tail is wasted). + */ +static int +vmap_bump_refill(gfp_t gfp_mask) +{ + struct vmap_bump_chunk *chunk; + spinlock_t *lock; + unsigned long base; + + preload_this_cpu_lock(&free_vmap_area_lock, gfp_mask, NUMA_NO_NODE); + base = __alloc_vmap_area(VMAP_BUMP_CHUNK_SIZE, PAGE_SIZE, + VMALLOC_START, VMALLOC_END); + spin_unlock(&free_vmap_area_lock); + + if (IS_ERR_VALUE(base)) + return -ENOMEM; + + lock = this_cpu_ptr(&vmap_bump_lock); + spin_lock(lock); + chunk = this_cpu_ptr(&vmap_bump); + chunk->base = base; + chunk->limit = base + VMAP_BUMP_CHUNK_SIZE; + chunk->bump = base; + spin_unlock(lock); + return 0; +} + /* * Allocate a region of KVA of the specified size and alignment, within the * vstart and vend. If vm is passed in, the two will also be bound. @@ -2519,6 +2611,19 @@ static struct vmap_area *alloc_vmap_area(unsigned long size, } retry: + if (IS_ERR_VALUE(addr)) { + /* + * Per-CPU bump-allocator fast path. On hit, no global + * tree work runs at all. On miss, refill the chunk and + * try again before falling back to the regular path. + */ + addr = vmap_bump_alloc(size, align, vstart, vend); + if (IS_ERR_VALUE(addr) && (long)addr == -ENOENT) { + if (vmap_bump_refill(gfp_mask) == 0) + addr = vmap_bump_alloc(size, align, + vstart, vend); + } + } if (IS_ERR_VALUE(addr)) { preload_this_cpu_lock(&free_vmap_area_lock, gfp_mask, node); try_init_free_mt_locked(); @@ -6214,6 +6319,8 @@ void __init vmalloc_init(void) init_llist_head(&p->list); INIT_WORK(&p->wq, delayed_vfree_work); xa_init(&vbq->vmap_blocks); + + spin_lock_init(&per_cpu(vmap_bump_lock, i)); } /* -- 2.34.1