From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 35BCE1A239A for ; Wed, 8 Apr 2026 02:51:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775616693; cv=none; b=gLTiL4xrb5LK7giMXJOLxOEA852AvBXrfPSNaUdsl9MBzjkmdDEGqQqFkS85nWPG6gNTjy8fkYlfeMT22xm2dJF5iTr4BiWcB9WShtHnY2j/ddEs5GNLLaEUTwRKsZEx0YyX/qW8BDvtxmji/cTq3lAfeOcTbp1Ly8x3tUeLUNc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775616693; c=relaxed/simple; bh=ZAYGoVOU/xBKdOabvdM+YHz4qLCWVs6z32hXbsZWLKI=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=OzYl/SHWAwWmomFdy4a3WzCzscIZaHz8HdMYnLrU7kNQ6q4oQ9H6Paygx6Fpl3idxFoeBVwLcO7SYAhht1z8II/Yo6r/6kq+y4KFg+rOvhJn2GTHjBZXJvYfyUia3hYnALKtcizlFEAKDBq986cd4ybDQBy5Rcd4WAvha/3QMEk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bGlckLx1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bGlckLx1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20871C116C6; Wed, 8 Apr 2026 02:51:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775616692; bh=ZAYGoVOU/xBKdOabvdM+YHz4qLCWVs6z32hXbsZWLKI=; h=From:To:Cc:Subject:Date:From; b=bGlckLx1cBnsEHrKYQQDWFEGJw8n34hukhP7o/9LIps1uAhfRIBIc7D1zccT9fcDY xmornJxJwwxJMSez+qRcwgSuvHPbPEnmHd1j0BeVr/H1FgTNIGOfoGgOIqQr9oR9hs V5CSoZMm80LxqS5Y7C1/smRaUcFTy9oDpk5DtKA2AaSIFSPYF5ZGCFKM7Tk3miJcNj GAh5hGPrnTeQsmrx434opxdiD94Qw3c0lAjUjJQY6j6CxuPU92j3euAsVqip4o030U 2kdXk1l0R4FW4SzBxRqGqUrR5qyoVeBUSd8a+Op0pA8z3Fe3kbraGYLqq+CwLz6DB6 bi9uYsaXIzyMQ== From: "Barry Song (Xiaomi)" To: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, akpm@linux-foundation.org, urezki@gmail.com Cc: linux-kernel@vger.kernel.org, anshuman.khandual@arm.com, ryan.roberts@arm.com, ajd@linux.ibm.com, rppt@kernel.org, david@kernel.org, Xueyuan.chen21@gmail.com, "Barry Song (Xiaomi)" Subject: [RFC PATCH 0/8] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory Date: Wed, 8 Apr 2026 10:51:07 +0800 Message-Id: <20260408025115.27368-1-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) 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: 8bit This patchset accelerates ioremap, vmalloc, and vmap when the memory is physically fully or partially contiguous. Two techniques are used: 1. Avoid page table zigzag when setting PTEs/PMDs for multiple memory segments 2. Use batched mappings wherever possible in both vmalloc and ARM64 layers Patches 1–2 extend ARM64 vmalloc CONT-PTE mapping to support multiple CONT-PTE regions instead of just one. Patches 3–4 extend vmap_small_pages_range_noflush() to support page shifts other than PAGE_SHIFT. This allows mapping multiple memory segments for vmalloc() without zigzagging page tables. Patches 5–8 add huge vmap support for contiguous pages. This not only improves performance but also enables PMD or CONT-PTE mapping for the vmapped area, reducing TLB pressure. Many thanks to Xueyuan Chen for his substantial testing efforts on RK3588 boards. On the RK3588 8-core ARM64 SoC, with tasks pinned to CPU2 and the performance CPUfreq policy enabled, Xueyuan’s tests report: * ioremap(1 MB): 1.2× faster * vmalloc(1 MB) mapping time (excluding allocation) with VM_ALLOW_HUGE_VMAP: 1.5× faster * vmap(): 5.6× faster when memory includes some order-8 pages, with no regression observed for order-0 pages Barry Song (Xiaomi) (8): arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE setup arm64/vmalloc: Allow arch_vmap_pte_range_map_size to batch multiple CONT_PTE mm/vmalloc: Extend vmap_small_pages_range_noflush() to support larger page_shift sizes mm/vmalloc: Eliminate page table zigzag for huge vmalloc mappings mm/vmalloc: map contiguous pages in batches for vmap() if possible mm/vmalloc: align vm_area so vmap() can batch mappings mm/vmalloc: Coalesce same page_shift mappings in vmap to avoid pgtable zigzag mm/vmalloc: Stop scanning for compound pages after encountering small pages in vmap arch/arm64/include/asm/vmalloc.h | 6 +- arch/arm64/mm/hugetlbpage.c | 10 ++ mm/vmalloc.c | 178 +++++++++++++++++++++++++------ 3 files changed, 161 insertions(+), 33 deletions(-) -- 2.39.3 (Apple Git-146)