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 65D2224B28 for ; Wed, 17 Dec 2025 12:02:34 +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=1765972956; cv=none; b=db5TZkIhXdwy/thbCTKEPzdmMBtmhN7IQCsWf0xZVuYECkv1KVYuDFmJE8E6vLhJPSwdwFahQa+GgjIu7nvSLj0EvZlBVo7m0mzCD4nb3LRIkTLa3xdRBOlPzxWj66iTQhZ8O/4JRqLPAYOLv0xiw550RxBaLl6feS+dQkURz9g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765972956; c=relaxed/simple; bh=07WXj93iwzpXfNKuQQBqBKXTNd33K7YBGjq4+7az0Vc=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SHWjfiuRkJwOmoNmsLNGmO4baPs+pkUqhM8+NqMTmqO19TnXHabxmohJBlTZXcKgCeS4YTV82LcjjlMFWBe7TtySah78HJ5L1evdFQB7/NWdU0a8fRITaXYpveON5GXw18Q+NhEXDghI3lbPc8x4ojpfmKug0zeD+bvBTGL1+WA= 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=TNLBtxe6; 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="TNLBtxe6" Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-597de27b241so7188999e87.2 for ; Wed, 17 Dec 2025 04:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765972952; x=1766577752; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=OJt3OeOAET42H1SZeq/73bRk3HyaCcKWTnzPipXTmdU=; b=TNLBtxe6s0hoKfGZtyvvlPMu6a3E8+YDIn+4J6LPiA89q47Rm2aURHFkpZdYWiZJEG V5qllclyQnj9X93LR+HgUFPEGct31obj1VyDjx9QNavtekChd4NZ0q9j86c2SaasfZoE L2SgwXpHq4pUcF0Dpg8Ui2n2cnUeKC+rLteI6P/EDym3UYFQBwr8nx79w3BWf+TzixOV wEzshW0kpPaMucfiB+K1vrwosy8fmXGi7IZ6uOiMLDs9K5Hn09fnlWDVw023FNhCKuMe W9yknHSbRqjYcVYiQclz3OQVVHhbORhjHCM7S0FvcsvEsDktJPgLmaRiWSJ2j0e0Y5v5 RTCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765972952; x=1766577752; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OJt3OeOAET42H1SZeq/73bRk3HyaCcKWTnzPipXTmdU=; b=R8oZ+CH2cQMbZJJIK+A4ozX2KvF90+BcDv2Oy6DmsAjYRLpBLJ4g4BvBaMPxW6Wdrn 6S9pgDyBYczsJBVVNKN+EsdCrKX+7EJsXTlmOGC9VuLR2sLQqyV3o+dpj3AK73hKd+yz +y9l2I/TCrWS4duYpkOwtTSQe/PejpQk22Hm07j1SWbpODaHGshhcFUDspsgjtQ0wyON oIB4GWzDDiA47Pk+iTQwOh+fbd4oTarMwDkYc5RKUWtmucuQS3MMZsYMFSasUjJv2GT4 LBilH7lYaP2LHqvcpHna2ootl2EnnRy5fdwkB/9qAUC5vIkL+83y2cbEzdGXFUCd8N7B 3gSg== X-Forwarded-Encrypted: i=1; AJvYcCXOMh0WpmSfB/NFV8UZXq8ChIDj7Gyi/UJo33h2tOeeyvAVkqy2tvhMuQ31lDgfpXJLhlFhystn0YuGR4g=@vger.kernel.org X-Gm-Message-State: AOJu0YypRyXH+I/fj0Ix4jEu59bk/Ke/Wi/ftBiqDG4OiLgvGiogLzZr XN8eK1zov4SG+BhcSOcWuBzzaTUipHTb+1f3VzxK/qbQqy8u1cCQtzW6 X-Gm-Gg: AY/fxX6ZvAEAWb4xZk549cjJWxBfL9lUNCctW2y+FeSXiXmC2dDDJ7EGJz4/NJa9zyC LRDaYh79c056LjyFW6pF+jjSNc8To1hJLhIkye3waE5asD88XJWfUc/C2GskjvRtpgmgR3eAyig xIsL/LPcCTB+6cTNt4XBFVwyHYALp3GNp8fVhvcWsoEuFxy8IDOjx2apqF6i5TJX5QqNnMgd4ey uv02CnJu5WGc6PINvjtOyRdyy0eQ/vWj5sRyoVrzdQx1QTpnSU+f2eyHfEMAcqu3FKLgwzOjBs7 LOgwcHTlXrpTZZnZ0xh+4Dz5FnXNRSCYyA/pfmzdCTfgRtLXfrmYOV0kS2h1ytVjt4zhftXl1ex G/dIcFCFqgJvWaen0RHM9uDjNrDGrr7se8orI/VqZY+qoImRmMGS8paz9SL0X83E= X-Google-Smtp-Source: AGHT+IEvC8B8oWcr0SIWQAYhh3wI3svFk5jPcenoh+vUpS22lTjVeH41fkW0PDI4QJj3OoDOzFAiww== X-Received: by 2002:a05:6512:3f2a:b0:595:8311:dc80 with SMTP id 2adb3069b0e04-598faa27bd9mr5964892e87.20.1765972952322; Wed, 17 Dec 2025 04:02:32 -0800 (PST) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5990da5dcdcsm2312647e87.73.2025.12.17.04.02.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Dec 2025 04:02:31 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 17 Dec 2025 13:02:29 +0100 To: Ryan Roberts Cc: "Uladzislau Rezki (Sony)" , linux-mm@kvack.org, Andrew Morton , Vishal Moola , Dev Jain , Baoquan He , LKML Subject: Re: [PATCH 2/2] mm/vmalloc: Add attempt_larger_order_alloc parameter Message-ID: References: <20251216211921.1401147-1-urezki@gmail.com> <20251216211921.1401147-2-urezki@gmail.com> <6ca6e796-cded-4221-b1f8-92176a80513e@arm.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <6ca6e796-cded-4221-b1f8-92176a80513e@arm.com> > On 16/12/2025 21:19, Uladzislau Rezki (Sony) wrote: > > 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. > > I wonder if a better solution would be "allocate order-0 if available in pcp, > else try large order, else fallback to order-0" Could that provide the best of > all worlds without needing a configuration knob? > I am not sure, to me it looks like a bit odd. Ideally it would be good just free it as high-order page and not order-0 peaces. > > > > 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); > > Would this be better as a bool? Docs say that you can then specify 0/1, y/n or > Y/N as the value; that's probably more intuitive? > > nit: I'd favour a shorter name. Perhaps large_order_alloc? > Thanks! We can switch to bool and use shorter name for sure. -- Uladzislau Rezki