From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F20D219FC for ; Wed, 1 Jul 2026 00:24:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782865487; cv=none; b=c7kuAvMpMmtr8V4k6bol1voSX88Zpm9zMIbr0it3kybVWIOuXF+WHrdHfXrAKJTwh1Q1Vi6C1kVQOIbR79BkH1V07xDctWa+v+6RQuU8TJv+TrEHk4NYv9spAOQtT5HFzdesXOH6G2xL1BUoeVw+nIekfaDXv3t1rdrS25cbRF0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782865487; c=relaxed/simple; bh=IesOUcqCmTJHw4XGUrRL85fxb+LG2Kk1aEb/sWSwEVg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AsJUia+LGo4Y/TKdn4TWa8SVPyl+PF6OQVOReehJmLh/i2r3ZrMNFRSiNvdTFKn2FSNUPvNAEgLJHuqL/dhZVpT7ncJBASFotWqKIoE3KTjUjr50Tut/zGpLDV6wJZ4mFECD2sw58wBYTXAbWyBJKdvad7f3GrwXbhH/LxzS1EQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AjLSjqyf; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AjLSjqyf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46AA41F01564 for ; Wed, 1 Jul 2026 00:24:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782865486; bh=xTs20CSuM/vUDmQtfbId0rl6VyghXk5EqBxIDAfWQSY=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=AjLSjqyfopAP4F3P6MxA0n61MZIsCi2dgOhDqP9s10/x0vSgtA3nd+udZr8SFIaom r244g2MCdIJZRY5Dx9HPDmz9aAsJ1rum/uyvox7y2kpnG8xveDGgr0mvxHHs7Ops2R cWlI5YosovpQKOSnB3MY+EQUYTTuCmVnMyAIMFNqwVYs0FcffkXCOH6Iis2xTgofZF PZErwryqzxdjnIDIV7x9zKiVDRiKqeBxdHeCwjHI8g2h3WotpjQPvPW8x2DplZ2hCw 5jN35/vlX1FX7VocSPEVx1YuiGljMnV0ymEPqDuMudhODogdNC1nB4xnv0PW3F+s96 M/EFFmiDQiv/w== Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-922ff615c14so6214285a.3 for ; Tue, 30 Jun 2026 17:24:46 -0700 (PDT) X-Forwarded-Encrypted: i=1; AFNElJ8JfuQDXYfzZSjvwYYKpRLcrcW0RFZtDS4F41mQunIV/C11F24KHwfIEGx+4EEirCswFb7vjqIguC/yjso=@vger.kernel.org X-Gm-Message-State: AOJu0YyjOP7fece1FwsRFEdRujzND92Yp2gj4WHy+s2wARz28u5mpRoW 3qYrv677FZ7akah7mF0ydkVtw7LHxWRig7E2ZS4O1ZRVg5KAg1iPowyG5dQ5nqRd1ZXp+VRzoyf GrgNC33hLc+cA0ianheEfWmpNUS2No/M= X-Received: by 2002:a05:620a:6193:b0:92e:6cd4:5892 with SMTP id af79cd13be357-92e6d859ad7mr510785985a.40.1782865485255; Tue, 30 Jun 2026 17:24:45 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: In-Reply-To: From: Barry Song Date: Wed, 1 Jul 2026 08:24:33 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AVVi8CeBGpmk77eMqTttSo_KxW3HiZzQmkhgUsiW6XCXi8DjH7cK85TxKK_kaqY Message-ID: Subject: Re: [RFC PATCH 0/8] Introducte Reserved THP To: Zi Yan Cc: "David Hildenbrand (Arm)" , Qi Zheng , akpm@linux-foundation.org, ljs@kernel.org, baolin.wang@linux.alibaba.com, liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, lance.yang@linux.dev, muchun.song@linux.dev, osalvador@suse.de, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, baoquan.he@linux.dev, youngjun.park@lge.com, peterx@redhat.com, usama.arif@linux.dev, willy@infradead.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2026 at 7:34=E2=80=AFAM Zi Yan wrote: > > On Tue Jun 30, 2026 at 6:59 PM EDT, Barry Song wrote: > > On Mon, Jun 29, 2026 at 8:20=E2=80=AFPM David Hildenbrand (Arm) > > wrote: > > [...] > >> > > >> > 2. Implementation > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > >> > In 2024, Yu Zhao proposed a similar idea: > >> > > >> > Link: https://lore.kernel.org/all/20240229183436.4110845-2-yuzhao@go= ogle.com/ > >> > > >> > The idea was to introduce two virt zones: ZONE_NOSPLIT and ZONE_NOME= RGE to > >> > guarantee the allocation success rate of THP, achieving an effect si= milar to > >> > reservation. However, it seems there was no further progress, perhap= s because of > >> > reluctance to introduce more virt zones like ZONE_MOVABLE. > >> > > >> > This RFC wants to discuss another implementation: > >> > > >> > 1. Introduce a new migratetype: MIGRATE_RESERVED_THP. > >> > 2. Introduce two new hugetlb-like kernel boot parameters: `thp_reser= ved_size` > >> > and `thp_reserved_nr`. When set, the required memory is marked as > >> > MIGRATE_RESERVED_THP and put back into the buddy allocator. > >> > >> I'm all for some mechanism to make runtime allocation of large chunks = of memory > >> easier, by adding a pool from where multiple consumers (THP, guest_mem= fd, > >> hugetlb, whatever) can allocate memory. > >> > >> Call me very skeptical of getting the page allocator involved like thi= s. (I hate it) > > > > One thing we've been thinking about for a while is whether we can > > introduce something at the pageblock level to let memory "remember" > > which allocation order is preferred within that pageblock. > > > > For example, if we ever allocate an order-0 page from pageblock 100, > > that pageblock would later prefer order-0 allocations. Similarly, if > > we allocate a large folio from pageblock 200, we would avoid using > > pageblock 200 for order-0 allocations as long as there is still > > memory available in pageblock 100 for order-0. > > > > Since order-0 allocations are often the main source of fragmentation, > > if we already have both pagecache and anonymous large folios, we may > > care more about containing or quarantining order-0 allocations in > > certain areas, rather than trying to maintain a large-folio pool or > > similar strategy. > > Aren't unmovable pages causing fragmentation? For movable pages, > regardless of their orders, they can always be migrated if no additional > pin is present. Right, unmovable pages cause fragmentation, but movable pages can also contribute to it. In terms of fragmentation itself, there is no real difference between them=E2=80=94the only distinction is that movable pages can be migrated or compacted. My point is that compaction or direct reclaim may lead to both allocation latency and increased power consumption, which may defeat the purpose of using large folios to speed up Android phones. Right now, order-0 allocations are spread everywhere, so compaction and fragmentation may be playing a ping-pong game and remain ineffective overall. Ideally, we should try to reduce or avoid triggering this kind of migration= , compaction, and reclaim. Our recent experiments using 16KB for both file and anon show that we still frequently enter direct reclaim due to memory fragmentation when allocating order-2 pages. In about 89% of order-2 allocation cases, direct reclaim is triggered even though there is sufficient free memory above the watermark, but no contiguous order-2 pages are available. These movable order-0 allocations, which are spread across every pageblock, are contributing to the fragmentation. > > If we use per-order pageblocks, how to use pageblocks with rarely used > orders? Allowing lower order to fallback to higher order pageblocks? Yes. If order-0 finds that all pageblocks associated with order-0 have been exhausted, it can allocate a new pageblock for this purpose, or in the worst case, fall back to a pageblock associated with a higher order. > > > > > Chris=E2=80=99s de-fragmentation of swap slots[1] seems to be a big suc= cess > > based on my observations, where he provides a similar memory-order > > preference for swap clusters. There is no reservation mechanism, no > > sysfs knob, and no need to split swap into two areas=E2=80=94everything > > just works automatically. > > > > I wonder if you would be interested in something similar at the > > pageblock level. If so, I=E2=80=99d be happy to work on a prototype in > > August. I=E2=80=99m completely booked in July. > > > > [1] https://lore.kernel.org/all/20240730-swap-allocator-v5-0-cb9c148b92= 97@kernel.org/ > > > > I feel that swap and page allocation have a fundamental distintion, > where swap slots are not movable, but pages can. Memory compaction can > move pages around to make space for high order allocations, but does > swap support something similar? How will page mobility work in this swap > slot defragmentation world? > > In addition, when swap space is full, or only order-0 swap slots are > available but higher order folios want to be swapped out, folio swap > might simply stop (except splitting folios to fill the order-0 slots). > But for page allocation, some pages can be reclaimed/swapped to make > space and this adds complexity. Yes, I agree it adds complexity, but it might significantly help address the fragmentation issue from a different angle. We used to focus on migratetypes, but now we could shift perspective and try to contain order-0 allocations, which are the real source of fragmentation. BTW, I haven=E2=80=99t started anything on this yet, because I=E2=80=99m no= t sure there is any positive feedback for it :-) Best Regards Barry