From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 F3D5B2264A8 for ; Fri, 22 May 2026 13:55:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779458150; cv=none; b=fuEItL506F51IWlAp5aYcqWz+8wokThLxeevEAWesuBU3jRBO8klcx8UfM1PJf907JawT0L0spYQvAKU9AHlP6FRS0PwIrTFvK3BlaCsR777ivhDA0d1Dnaby8699BOtQrfQVg9E6ijLmEvDcQWHIapHM7utsPBKXM7Jeo2O6N8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779458150; c=relaxed/simple; bh=P61U7lkls9zN8GrcHqrOCpgQWqKVFEtms/mpht+Mwm0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=HsT60NYfbD3CoownYucu4oicsplwjA6SRdsGV3i9jtx1MgsjQEniTz89saX+gnDwho08dzyTbBj0OlNFFN4iLBc0zCn2e0Umx8l1kNBcK5F+7DWHrpQgFQBv3pLYjQXA2m4Mz1pz2s6El31Vn0TefSyugqck4BmWt56AOrCpIBk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=M91x+LCT; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="M91x+LCT" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=P61U7lkls9zN8GrcHqrOCpgQWqKVFEtms/mpht+Mwm0=; b=M91x+LCTzySRq8TTvYUZyxpaY4 3riKnqxhPZc6qI1Lxl3jFmH3ot7B8IXmBFixGUa7+IL4Kl11C1BR4DqI5eqxiW3GCTdrh8a62xQbR GqscvWv+Sl7KFbqtqOC+TerCfrN08WwxxoRUEkXxyApZ5/MTrZXjLe6A1YqTsHHqwehcUWFnMuU6E UpW0VN2GWG4Vo/r2AOvKIoUAE7RLX7mA1OFzn8GUG74YOYoKnRQ3jgkNZM+arh0BuqDQyBJTm0FBm Db5SbsBGHcNiO7D4o00rd4V08dEMIdhFBdPB2yaVszOUXcnc2C9k8d1lbrfniqHsfHuvJfnTvUk2M ZP4OS2Jg==; Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1wQQLS-000000005EE-3wyb; Fri, 22 May 2026 09:55:22 -0400 Message-ID: <424ae0d6da89dcff3ef72711cc2323226e9f6584.camel@surriel.com> Subject: Re: [RFC PATCH 00/40] mm: reliable 1GB page allocation From: Rik van Riel To: Usama Arif Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, linux-mm@kvack.org, david@kernel.org, willy@infradead.org, surenb@google.com, hannes@cmpxchg.org, ljs@kernel.org, ziy@nvidia.com, fvdl@google.com Date: Fri, 22 May 2026 09:55:21 -0400 In-Reply-To: <20260522110257.1640781-1-usama.arif@linux.dev> References: <20260522110257.1640781-1-usama.arif@linux.dev> Autocrypt: addr=riel@surriel.com; prefer-encrypt=mutual; keydata=mQENBFIt3aUBCADCK0LicyCYyMa0E1lodCDUBf6G+6C5UXKG1jEYwQu49cc/gUBTTk33A eo2hjn4JinVaPF3zfZprnKMEGGv4dHvEOCPWiNhlz5RtqH3SKJllq2dpeMS9RqbMvDA36rlJIIo47 Z/nl6IA8MDhSqyqdnTY8z7LnQHqq16jAqwo7Ll9qALXz4yG1ZdSCmo80VPetBZZPw7WMjo+1hByv/ lvdFnLfiQ52tayuuC1r9x2qZ/SYWd2M4p/f5CLmvG9UcnkbYFsKWz8bwOBWKg1PQcaYHLx06sHGdY dIDaeVvkIfMFwAprSo5EFU+aes2VB2ZjugOTbkkW2aPSWTRsBhPHhV6dABEBAAG0HlJpayB2YW4gU mllbCA8cmllbEByZWRoYXQuY29tPokBHwQwAQIACQUCW5LcVgIdIAAKCRDOed6ShMTeg05SB/986o gEgdq4byrtaBQKFg5LWfd8e+h+QzLOg/T8mSS3dJzFXe5JBOfvYg7Bj47xXi9I5sM+I9Lu9+1XVb/ r2rGJrU1DwA09TnmyFtK76bgMF0sBEh1ECILYNQTEIemzNFwOWLZZlEhZFRJsZyX+mtEp/WQIygHV WjwuP69VJw+fPQvLOGn4j8W9QXuvhha7u1QJ7mYx4dLGHrZlHdwDsqpvWsW+3rsIqs1BBe5/Itz9o 6y9gLNtQzwmSDioV8KhF85VmYInslhv5tUtMEppfdTLyX4SUKh8ftNIVmH9mXyRCZclSoa6IMd635 Jq1Pj2/Lp64tOzSvN5Y9zaiCc5FucXtB9SaWsgdmFuIFJpZWwgPHJpZWxAc3VycmllbC5jb20+iQE +BBMBAgAoBQJSLd2lAhsjBQkSzAMABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDOed6ShMTe g4PpB/0ZivKYFt0LaB22ssWUrBoeNWCP1NY/lkq2QbPhR3agLB7ZXI97PF2z/5QD9Fuy/FD/jddPx KRTvFCtHcEzTOcFjBmf52uqgt3U40H9GM++0IM0yHusd9EzlaWsbp09vsAV2DwdqS69x9RPbvE/Ne fO5subhocH76okcF/aQiQ+oj2j6LJZGBJBVigOHg+4zyzdDgKM+jp0bvDI51KQ4XfxV593OhvkS3z 3FPx0CE7l62WhWrieHyBblqvkTYgJ6dq4bsYpqxxGJOkQ47WpEUx6onH+rImWmPJbSYGhwBzTo0Mm G1Nb1qGPG+mTrSmJjDRxrwf1zjmYqQreWVSFEt26tBpSaWsgdmFuIFJpZWwgPHJpZWxAZmIuY29tP okBPgQTAQIAKAUCW5LbiAIbIwUJEswDAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQznneko TE3oOUEQgAsrGxjTC1bGtZyuvyQPcXclap11Ogib6rQywGYu6/Mnkbd6hbyY3wpdyQii/cas2S44N cQj8HkGv91JLVE24/Wt0gITPCH3rLVJJDGQxprHTVDs1t1RAbsbp0XTksZPCNWDGYIBo2aHDwErhI omYQ0Xluo1WBtH/UmHgirHvclsou1Ks9jyTxiPyUKRfae7GNOFiX99+ZlB27P3t8CjtSO831Ij0Ip QrfooZ21YVlUKw0Wy6Ll8EyefyrEYSh8KTm8dQj4O7xxvdg865TLeLpho5PwDRF+/mR3qi8CdGbkE c4pYZQO8UDXUN4S+pe0aTeTqlYw8rRHWF9TnvtpcNzZw== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2026-05-22 at 04:02 -0700, Usama Arif wrote: > On Wed, 20 May 2026 10:59:06 -0400 Rik van Riel =20 >=20 > Hopefully will get to review all the patches. The above one of > kernel allocations falling back to small pages is interesting. >=20 > - Will it result in a performance impact as kernel allocations > wont benefit from higher order allocation? It might! We may well need a better solution here, like spilling over earlier, but limiting the number of 1GB blocks we can spill over into simultaneously (partially used for kernel memory). > - Will this impact 2M THP allocation efficiency due to more > fragmentation of kernel memory? THPs come from movable memory. With more 1GB page blocks not having kernel allocations in it, THP allocations should be easier. >=20 >=20 > > - movable allocations are preferentially done from clean 1GB > > =C2=A0 blocks, which have only free and movable memory inside, > > =C2=A0 starting with the fullest of these 1GB blocks > > - 2MB allocations follow the same strategy > > - 1GB allocations start with the emptiest clean 1GB block > > - if a 1GB block is mixed, with some movable pageblocks, > > =C2=A0 some free pageblocks, and some unmovable/reclaimable pageblocks, > > =C2=A0 the system has a free threshold below which only unmovable and > > =C2=A0 reclaimable allocations can be done from that 1GB block > > - below that threshold, no new movable allocations are allowed > > =C2=A0 in that 1GB block, while new unmovable/reclaimable allocations > > =C2=A0 are still allowed >=20 > by allowed, do you mean if movable allocations fail, it will > result in OOM? Yes, but by that time the zone free memory should also be below the low watermark, because there=20 should only be a few partially occupied tainted 1GB page blocks. If the zone has 300MB low watermark, and there are 50MB tied up in those reserved-for-unmovable memory areas, it should not cause early OOMs. I don't know if we can end up in a situation where somehow the reserved-for-unmovable memory would add up to more than the zone low watermark. That would be bad, and if it happened we would have to add some sort of protection against that. --=20 All Rights Reversed.