From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 54B0E2F1FE4 for ; Tue, 16 Dec 2025 21:19:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765919969; cv=none; b=HzEuMcjW0RqZB6kdAW7IuaCKsf7oAYD7BGwN989csV9yNvkPbRWivk6fTidyvDoQY9aiDz76GhFQ2IO2+6aXlDjDBcdamzaDuoqeEW+kDTT4BqVIkk4ZPCORIFY9Kjna8ZkaFui55DWDI/qD7j/a5lk+kceKCWYzZJIUR1mLKz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765919969; c=relaxed/simple; bh=Eth5ICmeVdmmUiS3DxRus0dnRzsAhXTEsiJ8J3Hp0/U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hUEBIXlZ7y6p+BTca66BWbewIN1iWL4QT+pp+D91nw4oa7QF8E3HlU4s4kxUs6VR7fa+btrd8XfPTfmOklMBT0Q8jc/EEUPAjmVQ64YiNVezGmHYHJTf9AV0SZaicMCFgNh9MWFfSI/J6lbtDGVBP7cWcWfUqVfcG1BIzOnTRYY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=I6aGbu5L; arc=none smtp.client-ip=209.85.167.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="I6aGbu5L" Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-597de27b241so6460135e87.2 for ; Tue, 16 Dec 2025 13:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765919965; x=1766524765; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3VY0ckxbD0HS7539qczsRu9OrZgCzKLM3XIDcEbqEpQ=; b=I6aGbu5L20Q+31ZGrefOaJWHNFtwgKNi+BSkO3AdRWpelH4V2uwEPNlFP52pDIPkTK GV1ICouhF68u347wxcmsAjfEBSpQd/rmQouvYnQEbiI8vRJdY1VO4sleBWXs9GFdJWIE JFY4j63caZSaeVynzSj2ir5RRvtaJUn3hHd3Dm579aOBeVLjkkSRS4l+rdyxLTyHjKfj ZNwx5GNrAAvyyIFa/pcgsMrHBhT3/w6V7hBBl0Slqr2pkIwloGBmF8J9UJJTAue6igVh +YgwdcnvqTOUGkJjUtgsCbJ/DS9FSnbfFDaDiX1vIBSsigpDVobiy+LybGUDHLB/ZbG3 fT7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765919965; x=1766524765; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3VY0ckxbD0HS7539qczsRu9OrZgCzKLM3XIDcEbqEpQ=; b=aGHTOQW+FkF8dXHdXDigc2mwsLrWWt6AdReL9ae8cXR+khAFNI64X5zBpgxw7l044v jDSUaiCHr7nX9oJKewOEHNWogIGiu+g0U/yJG1+uZPkwEkr2FpmUzIVJRiZ3+At6lQXi Y2E0PuwoS7e821VPh7cti95x2gadaT7VctcrJnETcxsPREy/PKFFC40brR4xmSl9+GP8 pLydS77+MxZf9Uqv4VtK4+OruwepU5UofmBVXCe9YCJTExMS9RM77bCCmHcXLCKRqii5 yAa1ytzUBnRta2D9Nuod3wsXZXK3xwhufhuUJHlJV/ox/bBq3B+4Uc9zJooVhqPm7Pxl 6PQg== X-Forwarded-Encrypted: i=1; AJvYcCVO6odzxkEwgabgQ0fTQVUcHGIthdZfBC1a4u+6QzfagR1BTNY6Ewdx4QGWMo4kGLY253sj+l26AIDDUn0=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+4/hZ6vgH+UcuplZqisRhZJfyHVDUSYCeBoqCI2IF9v/+BW/D qVgPvj9PUC9N4lDW7zt4XKUhJZjNCGNsF9Xo1Lp2puqOEmTMmUHEUgNl X-Gm-Gg: AY/fxX6Dz/EaPDRcsK+mxXkxQ6q0Fx2iIXg5fE1tf1URs2pYeD19yOXgJelrNINpZcW Dq7IpWOn3UpHpvKsPKNXTw1vDFV5ZoPAfRvYc0mmN4Br0hxpfZ1nm02ShxXHAjSFEo4ZHBMm8Rz ao56UYx3iWvRZS9qF9rsrvTVG76qWtC3NNGvX4f9MgcQMeTU18iCT9Bara+n8xYodz99aHWkP40 fq7lmGlxWcqMn9mGyf9kvjlpgDWblgnmrodq9YzqvRE/WNO9TRcYwUUwn6sVYNpWrzWr4bLZowE w9wsLBwGlgj0tWzEYjy46jEXUVDZIlus4tbVHxAbwFXjRIuc4hqAAOViMpj9p9CtGMdDyWSEsYn bMTxIlWxBBj8p6lvfIyxxzrZrKbHWcYx96Gao3QUJiqYGwszA4SnhDxpgH7KOW4EX67h5vbobch Hkh78= X-Google-Smtp-Source: AGHT+IH1n5Xidae/XzDPvmz1lzzFYToQR3yuOx1YHKy9VtOKOfY8zMAvZxcQt6qwuaMCIjDb5FeVew== X-Received: by 2002:a05:6512:131c:b0:598:853e:f26d with SMTP id 2adb3069b0e04-598faa8f1edmr5906744e87.51.1765919964970; Tue, 16 Dec 2025 13:19:24 -0800 (PST) Received: from localhost.localdomain ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-37fdee05901sm40926971fa.43.2025.12.16.13.19.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 13:19:24 -0800 (PST) From: "Uladzislau Rezki (Sony)" To: linux-mm@kvack.org, Andrew Morton Cc: Vishal Moola , Ryan Roberts , Dev Jain , Baoquan He , LKML , Uladzislau Rezki Subject: [PATCH 2/2] mm/vmalloc: Add attempt_larger_order_alloc parameter Date: Tue, 16 Dec 2025 22:19:21 +0100 Message-ID: <20251216211921.1401147-2-urezki@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20251216211921.1401147-1-urezki@gmail.com> References: <20251216211921.1401147-1-urezki@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce a module parameter to enable or disable the large-order allocation path in vmalloc. High-order allocations are disabled by default so far, but users may explicitly enable them at runtime if desired. High-order pages allocated for vmalloc are immediately split into order-0 pages and later freed as order-0, which means they do not feed the per-CPU page caches. As a result, high-order attempts tend to bypass the PCP fastpath and fall back to the buddy allocator that can affect performance. However, when the PCP caches are empty, high-order allocations may show better performance characteristics especially for larger allocation requests. Since the best strategy is workload-dependent, this patch adds a parameter letting users to choose whether vmalloc should try high-order allocations or stay strictly on the order-0 fastpath. Signed-off-by: Uladzislau Rezki (Sony) --- mm/vmalloc.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index d3a4725e15ca..f66543896b16 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -43,6 +43,7 @@ #include #include #include +#include #define CREATE_TRACE_POINTS #include @@ -3671,6 +3672,9 @@ vm_area_alloc_pages_large_order(gfp_t gfp, int nid, unsigned int order, return nr_allocated; } +static int attempt_larger_order_alloc; +module_param(attempt_larger_order_alloc, int, 0644); + static inline unsigned int vm_area_alloc_pages(gfp_t gfp, int nid, unsigned int order, unsigned int nr_pages, struct page **pages) @@ -3679,8 +3683,9 @@ vm_area_alloc_pages(gfp_t gfp, int nid, struct page *page; int i; - nr_allocated = vm_area_alloc_pages_large_order(gfp, nid, - order, nr_pages, pages); + if (attempt_larger_order_alloc) + nr_allocated = vm_area_alloc_pages_large_order(gfp, nid, + order, nr_pages, pages); /* * For order-0 pages we make use of bulk allocator, if -- 2.47.3