From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2E07A279DB3 for ; Fri, 12 Dec 2025 04:27:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765513637; cv=none; b=kiRNNGSXBrrWJKBmvASPMAiToNVA+qLsdlBXjmuFNaH8ogO/NvjO9lu2bXUMbVfj8LOK6FneiQf9oARV+Q+gyDg9VPjnr2sMo/Xv9WMmX30B6VAc4NWazspHdE8jQFuoKjDPEFmPBsvW8TtfpL804G9kDA2dv1vhSITnVi1rcb4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765513637; c=relaxed/simple; bh=EkGdkmUsvt2UR1IshFkgUUZoGUkUDyJ7z0vGOYuZu7U=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=gL/ja7Sa29xVdt/c1+NNzFi7E7nl+q6EyKu7EJ6B5Hqd+HTnHPjbIJUIiRNaVghGiP7rfWfVcOirhw8Andi+cTmZtRhp3xKzmh3zPBl13icX5F/81dFNwwy1QJ4h6BfBIpVz+WT6b1Qja927ry95fuCyD0bbz9SZD5YtR9NBNqE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 516231063; Thu, 11 Dec 2025 20:27:08 -0800 (PST) Received: from MacBook-Pro.blr.arm.com (MacBook-Pro.blr.arm.com [10.164.18.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id AD4853F762; Thu, 11 Dec 2025 20:27:09 -0800 (PST) From: Dev Jain To: catalin.marinas@arm.com, will@kernel.org, urezki@gmail.com, akpm@linux-foundation.org, tytso@mit.edu, adilger.kernel@dilger.ca, cem@kernel.org Cc: ryan.roberts@arm.com, anshuman.khandual@arm.com, shijie@os.amperecomputing.com, yang@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, npiggin@gmail.com, willy@infradead.org, david@kernel.org, ziy@nvidia.com, Dev Jain Subject: [RESEND RFC PATCH 0/2] Enable vmalloc huge mappings by default on arm64 Date: Fri, 12 Dec 2025 09:56:59 +0530 Message-Id: <20251212042701.71993-1-dev.jain@arm.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In the quest for reducing TLB pressure via block mappings, enable huge vmalloc by default on arm64 for BBML2-noabort systems which support kernel live mapping split. This series is an RFC, because I cannot get a performance improvement for the usual benchmarks which we have. Currently, vmalloc follows an opt-in approach for block mappings - the users calling vmalloc_huge() are the ones which expect the most advantage from block mappings. Most users of vmalloc(), kvmalloc() and kvzalloc() map a single page. After applying this series, it is expected that a considerable number of users will produce cont mappings, and probably none will produce PMD mappings. I am asking for help from the community in testing - I believe that one of the testing methods is xfstests: a lot of code uses the APIs mentioned above. I am hoping that someone can jump in and run at least xfstests, and probably some other tests which can take advantage of the reduced TLB pressure from vmalloc cont mappings. --- Patchset applies on Linus' master (d358e5254674). Dev Jain (2): mm/vmalloc: Do not align size to huge size arm64/mm: Enable huge-vmalloc by default arch/arm64/include/asm/vmalloc.h | 6 +++++ arch/arm64/mm/pageattr.c | 4 +-- include/linux/vmalloc.h | 7 ++++++ mm/vmalloc.c | 43 +++++++++++++++++++++++++------- 4 files changed, 48 insertions(+), 12 deletions(-) -- 2.30.2