From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (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 31DC32D7DCF for ; Wed, 17 Dec 2025 11:44:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765971898; cv=none; b=c6OcaudlQrPHK+wm6tN1oAoOEgejfU5njedkApknuRv99JN8Nlbo4B5KmqrD6qxucXDtjbFxI4rsE+QZKCzUuJ8QVTadneShAUlfHcMsjPj/OovJQ0VPRJwmUV6Ah4iEGtmNfmcFaM1w6N5/N1LFeNyKfmQu/hYC/BApRq9pphU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765971898; c=relaxed/simple; bh=YUqyjdYXXJosiapBAPYFct3NHgkMinGbtjwlPELSArc=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=amMTqi7eXtfwriBNMso69oCn6YJpu9i8+seIK+aOCDihcMrBmvQLn4viou9eh6xpfvHhPWacekZGbAuIw20dpi9t08u+5uETemf9LCo2Ct0T9wWv83TPEl0eFuYwCeXB8Z6jBeSGXoHMjbTqY5snPJNZYZdBkZJD4RcuI3zQPwc= 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=em/IESNz; arc=none smtp.client-ip=209.85.208.181 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="em/IESNz" Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-37fcec29834so39328661fa.0 for ; Wed, 17 Dec 2025 03:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765971894; x=1766576694; 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=WUxF2tYr95VdL4lhzoIMI5El8zC5jNsVaJWBiHVxrjg=; b=em/IESNzAHFFRaYbNccip/Gx6+7P61Rf6UG4lbCTf4jqyIgVnr0SEVDcTKjX+M1mNn FUM58LQLb37KY/OSkNhRzky7FguhSrIaDEkJIfiXhJIBuXhTw0Jhak2b+8WwdyaB4Sre 3jDyvK977/xcYuLt6135/aWzeoqH0I6oM4BrisLkc7SteBnAG13uOCEkYbtSHGoQgiQJ f2vflYykruVujjWkM1vuVdYeCM34a4gAMn0BVwEqjn+OcenYPSoJNU0dDanDlQPhAcLj f53hn8xo9sXzNJbOTcL7isuNzp5KAuHlgUyGLDW4aQhSaTp6hjESIQLBQ6ucTl4ntw4e OTLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765971894; x=1766576694; 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=WUxF2tYr95VdL4lhzoIMI5El8zC5jNsVaJWBiHVxrjg=; b=RBFGqAoW/Fg2yxlQ01iCFGFV8zzi4YWed6jvPGm/r8yDofaJoNeQ4+wWRCFsJ7z5cb 1HKFJDhhPOLfZTGG/e3T8PegtM9Phvt1rAqLl2vhRECtc/1OfRSGUOnQFZ+md3ABWHL7 ZtU5WAuyh1J5sHdRAdMud1QhRCWgf6DUCu6O81LzS0JulcPSrzGaNssmp5Y8DpOqKzPT IIiLkw43nHJcwP+1ibMLZ6auzP1GgRPvPfg3WYR5evU9YGYIkP4zOBLh0yDWfAVBM+4F S4gs++BJViZqulF6cNPmDYKe37eSmaxsRWk/0X3qHEQT/yg3UGj7h9hFt8vIl+E17pvz 7Jaw== X-Forwarded-Encrypted: i=1; AJvYcCVotGcOXjgdUUJfrXuzpRtx7HbWnlSVDyA9JEZ+7TvdAt+d3VjGDlekmM8ZG1EuQKM6HHEA63H40n2bivg=@vger.kernel.org X-Gm-Message-State: AOJu0YwN7X/UMwJ85fnvVBE5TlX72oAX7YzUXBfUQtIi87tJY6QlD7iq /4IT+1yFs/SvtBSxN/1gJoZvuJERmvRkRGViWsZePLJ3igs5ZiLwDhzo X-Gm-Gg: AY/fxX5/nnoGhNsylBIICIhPR1NyCdaI3QhF5qG2cc1sMj6drzMuY2WXoHDjX/XicJK gg8A0EfFVVOGWajkwjrOfmZ0P+S0zB2Ey476aFswKc2ZvLUVu4LShg9bSj6kXNXl6fqcTSsHegR MBDdV3L/r5jlKm8Pr/hQHLohTnPy+CvevMfLBUkOaGRj0HaxIROKPEM4BiAv/n+qxNhGbJUeS+r p11CCzUuYF8hEqPQbTYmkoTP/uGana7sL8BSk8+CZFOE35AKxEOxBwbeL/xzcEXkvaKZAgeDL0H 7ct80Wm6bDEcasAC6WYG0HzRJMNV42IjTqWyoQmkJ3ooNjPKTX4STmF+gvfSSBhn23wNSswrcs5 1KYsN58j23xEiIp362D2lU40TPbwu6zGrkj/SE1LT0W9CIR4xbVkO X-Google-Smtp-Source: AGHT+IFnlFMh5lGk/zOymI8BJbm3P4LKts0zX06lNX7DArcdydKILQKJcbozknenpOui7kZh85vmCg== X-Received: by 2002:a05:651c:418e:b0:37b:9e0b:e0d8 with SMTP id 38308e7fff4ca-37fd07a7c5cmr44972801fa.14.1765971894030; Wed, 17 Dec 2025 03:44:54 -0800 (PST) Received: from milan ([2001:9b1:d5a0:a500::24b]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-37fded75d8esm50309421fa.27.2025.12.17.03.44.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Dec 2025 03:44:53 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 17 Dec 2025 12:44:51 +0100 To: Baoquan He Cc: "Uladzislau Rezki (Sony)" , linux-mm@kvack.org, Andrew Morton , Vishal Moola , Ryan Roberts , Dev Jain , 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> 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: On Wed, Dec 17, 2025 at 11:54:26AM +0800, Baoquan He wrote: > Hi Uladzislau, > > On 12/16/25 at 10:19pm, 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 > > I don't get why order-0 do not feed the PCP caches. > "they" -> high-order pages. I should improve it. > > 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. > > And when PCP is empty, high-order alloc show better performance. Could > you please help elaborate a little more about them? Thanks. > This is what i/we measured. See below example: # default order-3 Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3718592 usec Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3740495 usec Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3737213 usec Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3740765 usec # patch order-3 Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3350391 usec Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3374568 usec Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3286374 usec Summary: fix_size_alloc_test passed: 1 failed: 0 xfailed: 0 repeat: 1 loops: 1000000 avg: 3261335 usec why higher-order wins, i think it is less cyclesto get one big chunk from the buddy instead of looping and pick one by one. -- Uladzislau Rezki