From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 88E2640243D for ; Thu, 30 Apr 2026 12:09:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777551001; cv=none; b=oheVexdmU3CZqAKmkzp98AuQrrrFcjm50hu3/xg076VCUbahNVBfAAQbdsgmWhjf0QiP+LEccYDa+cv1Fe2KuhuIJKqfOgt3gj0LFYJMUG5wqlxDlD06rpQ3hTqyjtleX1SRkqY6ocMWwu9nYeBNu8ygcdUsy2lnVXKDnuFoxOs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777551001; c=relaxed/simple; bh=tj+gg8pp6MdmiyOh+6dl3NjIPWGm6gpjZAsvRUJFhEQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=akKDMflpkQq5CyMbP6DAXEUPNPYNqbB+FRlZjgWEStnwiuFUv9c0rJGWO4atq6iZkStsdTBxZONVsjFogDjPxPlZmG1JyXCCYCGmXZYUlzueDHI3RvoMtFmpIvr3Yo0mL367yCykDx4ZQlehte+6QJ+KHDlGMpsuZ0MVu3TVsug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=ujrGB/bi; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="ujrGB/bi" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4852a9c6309so6781645e9.0 for ; Thu, 30 Apr 2026 05:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1777550997; x=1778155797; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=BM5KrwxlYL2yWx54/IrxJMUv0ov8gisDWiwFBM3mToc=; b=ujrGB/biKMvIU301bI5bggwK9bIbKZvq6gJlEywVIzrNtHbTzLzA+B35VDlzJDCrLi vTW3VRXzjpiNdMbbc7pR0JyZZHJYrm+kBogYukSkayecocvbYDJKuq12P+9s7mrckPaD UyAQ2mUK8KampyCFDm1VnvttxKhqDp2t509GIe5JliGZL5eLomm3uZ6Z+Y9BkqNtH73/ +014WbH4uR2kFl2+sFMa+V4lhx9BB/igVcSHQgp4t7Kw+OYa3DPlpq3AlrVkianYJeCC KR17xTM++F10SWRljUBqA7zb6C0cnAhhILq/GiMGaYsnl9jQprUSueMZajeFGxzVPtu0 p+Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777550997; x=1778155797; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BM5KrwxlYL2yWx54/IrxJMUv0ov8gisDWiwFBM3mToc=; b=pq/YJvIJMybXNJ4FqjNRpaFdCKLJGyjdRgT6FjkZe/TUAD/maIhBHIZph1x86CCF6J AbzHhakIAL9nhdSZPZnkal6vb8pX9UzokV9HOu/SeOk8yLKZrRznMNC6F8oSCZdDeSy8 O5pnoDtqP+TrP9h3pdGSlb1xr+kRQjJQp+P7hYM7CpuacHbLuFUb91WPuux7RBRavBFV V04Bq7OAZ6wuMPjmH4ZTXXTyK02GFBkIM3ZZYwigIXXwrgjQxKRvLe6LhCTKNZrwcXan UJZ19BcaaohxxtbPfs0YLOlxK2ek3Gl4rSSUYwFxQboUUTPx5bFfS9uXDjIgIkkhZjD4 sH6A== X-Forwarded-Encrypted: i=1; AFNElJ9JRHLWOfCpN8H/pNhWG5zte6VVvpPcCQ9PiaQDCx4/K3XsJzRueovM64PVkAkFV08n9uXAVUXtxoL6OlI=@vger.kernel.org X-Gm-Message-State: AOJu0Ywo4sKa3I6cFFT6Qw1mQA+JwLHkaDRjoeDAny6w0hpOqJDCSbxe ZqlJQNG5XpryEUtcb/omh7y3yY32IbQgUsA3GuW+s/evcXahAErkDPV9tzk6TiuNOcQ= X-Gm-Gg: AeBDietpzGt4pnPkev9kR2UDpfqYIU2fIlQWWPEfGAzrynLIIiF+DAKMQqEeaApoEKz hma7Trp4q997+6DZKxygpfh2wqlKwZBIYrt4Ph/JuTVOES2EafFVYSZW1/YKu/LgxPkoqQN7Too 6pth1FJ9yfbqp4ivTdN+WD8AzcQlglkdfIedMurHuGgr+mD5aBk6OmXFExKXb6Q2H9EH0MWtmT9 kYfoPzcTeqc6XxO/jvThdG2d1RL5RblwKKR56Js94t9vAUnlNy//OFBKBwlX9+ur+uXKjyKM8r3 S7hEGGxoV2EDRTK3xOF7Y4yf53SZCffFLq3H24SBOCeNdszBt9Z0aL/USIauZR5hd+XWG0H4NJU DRV3U09m6RZl50+DxElENxqM3umF12e+OL36qnLuvm7o1TK+fa/L/ueXtOQhHw8TqsJ4bLgRZsu /9iuYopj68s9K0JORHl2S7Aq2YQQ== X-Received: by 2002:a05:600c:5254:b0:486:fbdb:b718 with SMTP id 5b1f17b1804b1-48a8445f451mr47883195e9.25.1777550996490; Thu, 30 Apr 2026 05:09:56 -0700 (PDT) Received: from localhost ([2620:10d:c092:600::1:2d86]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a824f9f0dsm58153455e9.15.2026.04.30.05.09.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2026 05:09:55 -0700 (PDT) Date: Thu, 30 Apr 2026 08:09:50 -0400 From: Johannes Weiner To: "David Hildenbrand (Arm)" Cc: Ryan Roberts , Andrew Morton , Muhammad Usama Anjum , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , Uladzislau Rezki , Nick Terrell , David Sterba , Vishal Moola , linux-mm@kvack.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, david.hildenbrand@arm.com Subject: Re: [PATCH v6 0/3] mm: Free contiguous order-0 pages efficiently Message-ID: <20260430120950.GA1738@cmpxchg.org> References: <20260401101634.2868165-1-usama.anjum@arm.com> <20260429103326.GA1743@cmpxchg.org> <20260429050430.d86f01dbe731edc9fa932add@linux-foundation.org> <9834200a-492c-4705-a2b2-e76cc0ba5392@arm.com> <4ff3d230-d48d-4a9c-aac8-30a7b80c4775@kernel.org> 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: <4ff3d230-d48d-4a9c-aac8-30a7b80c4775@kernel.org> On Wed, Apr 29, 2026 at 03:04:16PM +0200, David Hildenbrand (Arm) wrote: > On 4/29/26 14:31, Ryan Roberts wrote: > > On 29/04/2026 13:04, Andrew Morton wrote: > >> On Wed, 29 Apr 2026 06:33:26 -0400 Johannes Weiner wrote: > >> > >>> > >>> I think we should revert the original patch. > >>> > >>> The premise is that we can save some allocator calls by requesting > >>> higher orders and splitting them up into singles. This is a frivolous > >>> and short-sighted use of a very coveted and expensive resource. > > > > I'm not sure it's that simple. First off, vmalloc has preferred to allocate high > > order pages for quite a while, it's just that the patch you're referring to > > makes it try even harder. So reverting the patch doesn't completely revert the > > behaviour, it just reduces it. > > > > Performance benefits because those high order pages are mapped appropriately in > > the page table - i.e. 1G PUD, 2M PMD, (or 64K CONTPTE on arm64). So it's not > > solely about the number of cycles spent in the allocator; the HW is used more > > efficiently. vmalloc only splits to order-0 for the benefit of the caller, > > because there are some places that assume they can access each returned struct page. > > > > And all the order-0 pages of the original high order page are freed at the same > > time, so it's not like we are destroying the contiguous resource; it remains > > intact for the next user (well, ignoring that some will be freed to the pcpu > > list - this series solves that wrinkle). I've heard it argued that this approach > > is actually _better_ for conserving contiguous blocks because it's keeping the > > lifetime of all the constituent pages bound together and reducing fragmentation. > > I've never seen any data though... > > Right, that's what Willy has said: allocating+freeing larger blocks, especially > for unmovable data, reduces fragmentation as a whole. And that theory makes > sense for me in the context here. Do we have data confirming that it works out like that? I think the missing piece is that as long as we still *do* have small order requests with mixed lifetimes, they will punch holes and cause fragmentation. Large requests need to clean them up, which is expensive. You can of course make the argument that it's really the small requests that are the source of the cost. And I would agree ;) But adding higher order requests right now surfaces that cost. We've seen that everytime in real workloads: THP, the large page cache requests, and now vmalloc. They all increase compaction rates, cause failures in higher-order network atomics etc. I do appreciate it's a chicken and egg problem. But I don't think we can justify regressions from now until there are no more small(er), fragmenting requests. So we should still require some form of amortization story when we add larger requests. It's not accurate to say that they pay for themselves right now. And the small cost reduction in the vmalloc alloc path does not offset the externalities of consuming contiguity, not by a long shot.