From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f46.google.com (mail-yx1-f46.google.com [74.125.224.46]) (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 927D5353EDF for ; Sun, 5 Apr 2026 23:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775432103; cv=none; b=jwniMP7gIUU+bXWO6ynrHcdTju71r1jRADO8X/fnS0GiuOV+Ov5Lmwst801rZn6SCNUyxC1uA1T6iMQy97ca+nVZgmVyzHMmZvH24d8udfXvh++YBJaFQV/nANJe8q28tfCzC2TDy81v+WJEVSOF7My3TrJH2sVG9Vdf0BgRg5I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775432103; c=relaxed/simple; bh=B7cuyw9xySPaJZtqPzWi7xYG+G28EUTfrjGcp+C9qQM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=cRLONgkJ66DFXxh8M/zYCTpi/6OXMiIqKAC9yCRr1OmWK739ZvZ/ovS8D0ycHOUS+shR2xzpfRbQAc9+jL1jkmhmZ4Wyf0HRL2JlmF2SeFZKE7toYTLKnEQtLiFRmWLzOfFIPqjv+bSGHRrWZwAc4WoGKVhjFp4lRdpNeg0FRt0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=gGYj0yKt; arc=none smtp.client-ip=74.125.224.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="gGYj0yKt" Received: by mail-yx1-f46.google.com with SMTP id 956f58d0204a3-64ee82e853cso2517368d50.3 for ; Sun, 05 Apr 2026 16:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775432101; x=1776036901; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=Lzm3/9j9sm7zHb61fOGxB4CuuzgAL6dQcGBwWJvxxMk=; b=gGYj0yKt0fTN3XN/Z3yOfJTViI+QcfhHaBnP421xurxA/CdMFgwjCtv5t4+xvmiUah 0/aZV+9zgPkivSFWLqOtNFfuC+ewiH4vT8fsZY2l03uRTw25KQbfTdSpabRubf+0aUuc wLBv+Vvu18Yop/Ps1RI7ckqWEkMzcuQMert+2NiwOMw3aOySeBtez/mbfrw+cyFyVUGa FCUrMCijD8Cn/39lCDbZ4fQ5dYZ6pZgtnUtRficpKlqJBp9Ynp2AvvqTNmC1oP2chTW0 kC6EM1CuBPC9WxcfNH/VRKhgAAJaKdpr2LJ4pL89AwHZsXIl031QhkwcIAqVlaoYHVxl a0UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775432101; x=1776036901; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Lzm3/9j9sm7zHb61fOGxB4CuuzgAL6dQcGBwWJvxxMk=; b=fC4/0Q47M/jzjMUVSBqPpFFrLJtN1GmzjTs1B4DzVOso+k5v2gDuty03ooOyBVajfz 4MDKKJF2aPYncnyhRID57xpKnMLXV9VeA4rqs1u8bgWye2TsKUkIZxxppqX5E0G65cQZ S5Du/N2G6amK5w6ElH2yyRNtvnMB0YbF4xFxs0h3n90oUMNRatvallnfQeoe9ncbjQw2 0rPXw+TUyxHayVM/ipdyOhXhHpZCZ0NrNi+S4JqB015/FNEjlxHsWT3vGrTr0jnUO6lp tSNyPGl+5HQ3sg3WWmj5bpP060WpVmzvBeIx+bFttHcDC8oFB1XV0pC2n7oqIUtavpDy nd3A== X-Forwarded-Encrypted: i=1; AJvYcCUoDXhE9e8KiD4zZxG00WJsfo4EFC/uTb0IXlYEp1sPaHfvP/OgVluQ2Y4gKF9AjU741GfGb8jSlBj7S6c=@vger.kernel.org X-Gm-Message-State: AOJu0YxFH4DqLQGocm5Wvp6tTg0uO2JMnUTbpiX88JQIBy334R+4vgwe LyOSapixES8ouBX9pqxlJEbquRFx/GSSGlT61r4utTXCg3sezrRp89b31zO5UZga7w== X-Gm-Gg: AeBDiev4MnxuF0VOOLv/bPg+eNKrL4suM6wduMXFzWY2HA5/9AY7xaDykps0BjJeYSo EBJi8mQfxETUISD+qEG3/lA1AJ5p1ysHixYE7oMI49bwJHDSEppHXSIJIpUHFIkjT3+utR/0WFw UlkucZfEwy+cDzqYW12ayUXgRITs2b9JMQKusKNtRYPac/H0Zyd6H4RpjXCzMsBm0B8iz6AuU0Z NrEpRVqr4XGyrJzEyU7+AdNZyoEoDmz6/kRYpZf0ZZE5fr7GQ/hWlKc6n+/cjw2q0nSPJ50ZYEE PLYRky2FJ9EsZCeCH2nlrBcIw/3dkyUcR89W9r8vNKPul9TJagCZrLl/xVCzukCo1gpQWZYAS7I BMNMx5EeFTD5T+deEg0QBpq9sh2wHQBYaEwQcZBALhanRWtxoTO4Yws1IBIys3yC83wo+NZzO+x 9mLb0gdqOJZv79NnEfHMg1NCUVafwD3iPmdp3oo0p3XoDaaIs3ixKtl1K1g778cmtGqtEEh982h WMSJE/BC4Y= X-Received: by 2002:a53:b009:0:b0:63e:2715:5ac6 with SMTP id 956f58d0204a3-65048828b7fmr7933343d50.35.1775432101086; Sun, 05 Apr 2026 16:35:01 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6503a83adc3sm5317274d50.5.2026.04.05.16.34.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Apr 2026 16:35:00 -0700 (PDT) Date: Sun, 5 Apr 2026 16:34:46 -0700 (PDT) From: Hugh Dickins To: Usama Arif cc: Andrew Morton , david@kernel.org, Lorenzo Stoakes , willy@infradead.org, linux-mm@kvack.org, fvdl@google.com, hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev, kas@kernel.org, baohua@kernel.org, dev.jain@arm.com, baolin.wang@linux.alibaba.com, npache@redhat.com, Liam.Howlett@oracle.com, ryan.roberts@arm.com, Vlastimil Babka , lance.yang@linux.dev, linux-kernel@vger.kernel.org, kernel-team@meta.com, maddy@linux.ibm.com, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, linux-s390@vger.kernel.org Subject: Re: [v3 00/24] mm: thp: lazy PTE page table allocation at PMD split time In-Reply-To: <20260327021403.214713-1-usama.arif@linux.dev> Message-ID: <6869b7f0-84e1-fb93-03f1-9442cdfe476b@google.com> References: <20260327021403.214713-1-usama.arif@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463770367-802286629-1775432100=:17421" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463770367-802286629-1775432100=:17421 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 26 Mar 2026, Usama Arif wrote: > When the kernel creates a PMD-level THP mapping for anonymous pages, it > pre-allocates a PTE page table via pgtable_trans_huge_deposit(). This > page table sits unused in a deposit list for the lifetime of the THP > mapping, only to be withdrawn when the PMD is split or zapped. Every > anonymous THP therefore wastes 4KB of memory unconditionally. On large > servers where hundreds of gigabytes of memory are mapped as THPs, this > adds up: roughly 200MB wasted per 100GB of THP memory. This memory > could otherwise satisfy other allocations, including the very PTE page > table allocations needed when splits eventually occur. >=20 > This series removes the pre-deposit and allocates the PTE page table > lazily =E2=80=94 only when a PMD split actually happens. Since a large nu= mber > of THPs are never split (they are zapped wholesale when processes exit or > munmap the full range), the allocation is avoided entirely in the common > case. >=20 > The pre-deposit pattern exists because split_huge_pmd was designed as an > operation that must never fail: if the kernel decides to split, it needs > a PTE page table, so one is deposited in advance. But "must never fail" > is an unnecessarily strong requirement. A PMD split is typically triggere= d > by a partial operation on a sub-PMD range =E2=80=94 partial munmap, parti= al > mprotect, COW on a pinned folio, GUP with FOLL_SPLIT_PMD, and similar. > All of these operations already have well-defined error handling for > allocation failures (e.g., -ENOMEM, VM_FAULT_OOM). Allowing split to > fail and propagating the error through these existing paths is the natura= l > thing to do. Furthermore, if the system cannot satisfy a single order-0 > allocation for a page table, it is under extreme memory pressure and > failing the operation is the correct response. >=20 > Designing functions like split_huge_pmd as operations that cannot fail > has a subtle but real cost to code quality. It forces a pre-allocation > pattern - every THP creation path must deposit a page table, and every > split or zap path must withdraw one, creating a hidden coupling between > widely separated code paths. >=20 > This also serves as a code cleanup. On every architecture except powerpc > with hash MMU, the deposit/withdraw machinery becomes dead code. The > series removes the generic implementations in pgtable-generic.c and the > s390/sparc overrides, replacing them with no-op stubs guarded by > arch_needs_pgtable_deposit(), which evaluates to false at compile time > on all non-powerpc architectures. I see no mention of the big problem, which has stopped us all from trying this before. Reclaim: the split_folio_to_list() in shrink_folio_list(). Imagine a process which has forked a thousand times, containing anon THPs, which should now be swapped out and reclaimed. To swap out one of those THPs, it will have to allocate a thousand page tables, all with PF_MEMALLOC set (to give some access to reserves, while preventing recursion into reclaim). Elsewhere, we go to great lengths (e.g. mempools) to give guaranteed access to the memory needed when freeing memory. In the case of an anon THP, the guaranteed pool has been the deposited page table. Now what? And the worst is that when the 501st attempt to allocate a page table fails, it has allocated and is using 500 pages from reserve, without reaching the point of freeing any memory at all. Maybe watermark boosting (I barely know whereof I speak) can help a bit nowadays. Has anything else changed to solve the problem? What would help a lot would be the implementation of swap entries at the PMD level. Whether that would help enough, I'm sceptical: I do think it's foolish to depend upon the availability of huge contiguous swap extents, whatever the recent improvements there; but it would at least be an arguable justification. Shared page tables? Generally I run away, but perhaps manageable in this limited context (a store of not-present swap entries, to be copied on fault). Hugh ---1463770367-802286629-1775432100=:17421--