From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2221BC79F82 for ; Fri, 4 Sep 2026 15:11:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7011F6B009B; Fri, 4 Sep 2026 11:10:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D83D6B009D; Fri, 4 Sep 2026 11:10:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A1226B009E; Fri, 4 Sep 2026 11:10:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 34C446B009B for ; Fri, 4 Sep 2026 11:10:43 -0400 (EDT) Received: from smtpin12.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BE1098015D for ; Fri, 4 Sep 2026 15:10:41 +0000 (UTC) X-FDA: 85176416682.12.869780D Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazon11013007.outbound.protection.outlook.com [40.93.196.7]) by imf30.hostedemail.com (Postfix) with ESMTP id D33768000F for ; Fri, 4 Sep 2026 15:10:38 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=UZoxQoc+; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf30.hostedemail.com: domain of ziy@nvidia.com designates 40.93.196.7 as permitted sender) smtp.mailfrom=ziy@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1788534639; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=55CKOlJDuzcxiVxXB/ipq9IEKZ5il8Exdsy9b4Arfvo=; b=JPHB6Ye0DGBPAgsVX6HsaQlG+a8QROBwz3ORAjKknzA6OrehTp/fTltpR1xdm/cnB3gyye RhV9e0CyFnuL8Go9OPsD/j7VvLOkEGKevTLm2kw4Cg5VL/QEff0S1AgLXjRIdhp2/9G5Vt fBrY1LRb69ha5yvC8zkdzIuuUHswH/Y= ARC-Authentication-Results: i=2; imf30.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=UZoxQoc+; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf30.hostedemail.com: domain of ziy@nvidia.com designates 40.93.196.7 as permitted sender) smtp.mailfrom=ziy@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com ARC-Seal: i=2; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=pass; t=1788534639; b=bUIUoD1MZV4MqSrPLWbMH9fZBe7fIopnGCuiS2Jwrh6wKxuwTeKQf0vUf2zXXJWcCvrOmD eP6zWNY5TSeEzBDkfXRtQUv9NePZkhqQW7fsjEhYpOQBth44i8alSB1LQDlJnVhizcNLlf ebeyULJcz8GgTbQLxBYpvjMSbgWL/Is= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vFOCJBFQTfWdjtVEAVoTCZzxbWR7ogIKcJb+QSEtAWYBqmdDo8Z6ia6bTOSbFgVVbF/2V1lCzztoLZMLoPbPXdl1W02Jz+WL0Cv7MIEe5Yh03yUff8Jf/0/w2PLrd4rjj1yLMl/DTX5DXN8cMhse8TN1nqZE96QWnjG+/zWHXr41iXq+BbEKH2R0JfynNoJagk1N2T6MDX2ljqufL1685tV3DseYaqXiYf1eS2LQDRm5feleYnsk9GfSk989LNLcWSbVvA7sva2qq25yWzRe7mfM+zTkwuulycmuIC8lU04oNaCag/XmjcD0EV8uTasjugR8JftGFI1UWmvX1Gb1Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=55CKOlJDuzcxiVxXB/ipq9IEKZ5il8Exdsy9b4Arfvo=; b=SPab+2oD3D++53oPB4wq3oDnmCDBYPEOC2liuyoLvvslK5kysVeqwPom4+s3i0tVOOsmVNPOzJEGpXIkgo69dkdWnz0WlSLKkrk8jbfA6rBJlGoa7TqeVS6K0EIgNZqgIUGx+1X/4S87ptWeP+z9A3AXdriUr2QPrqMMy04JRbXKDjg4d0cPVWYXEpkJ5QRMBhXgRBYlFJQ5utR6H6RKuab2Y//UM2Xs55kqhfk2ylVf5dIa9KgfzY+RdwFbr6bC5sw16A5h6ywYvI6/Ig9zjYW1mgzaIemScsEURqYYy/MZMxyV8oKHq4RJciNoDqjNM1B1yk1hY6Khzkmc0UeT3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=55CKOlJDuzcxiVxXB/ipq9IEKZ5il8Exdsy9b4Arfvo=; b=UZoxQoc+hqybpr/8bJKrxIebvTegZx05cSQksLdE/uQeQnCzXrB7g5rCkRHOdv0DX8qBYLAnFD9xhFr+rXQ6PG7Ljg8h3+WAE3llp/Q7ygSp2aQjn8cYRELBg0piWJO/ADkszDZNC9jEx3P/gWUYoBuPrtrTiPxXf7590dxP5nEm0fA8T91gv+IpZvCHS+ZmkDgNMA7AavkOD5O9jC0EY97jyiWpgJQPrDnri8ziHr1xAMgMZo3fRNJYQBMdt4b7EsJjzCznz4PB7f2UCbV7aIzJMqr67uUSSRcyCC2M9lHJVjPLZLha9bsTlpqJOt77Wrw90d4nwSubtVpqPNtHeA== Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DS0PR12MB8502.namprd12.prod.outlook.com (2603:10b6:8:15b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.13; Fri, 4 Sep 2026 15:10:30 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0360.008; Fri, 4 Sep 2026 15:10:29 +0000 From: Zi Yan To: Qinyun Tan Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , David Hildenbrand , Lorenzo Stoakes , Baolin Wang , Xunlei Pang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Chris Down , Chuanhua Han , Kairui Song , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/2] mm: memcg: settle memory.high debt after THP faults with non-blocking gfp Date: Fri, 04 Sep 2026 11:10:27 -0400 X-Mailer: MailMate (3.0r7028) Message-ID: <6B46E8DF-679B-4254-A4AF-7B992B0F6460@nvidia.com> In-Reply-To: <20260904035407.4098627-2-qinyuntan@linux.alibaba.com> References: <20260904035407.4098627-1-qinyuntan@linux.alibaba.com> <20260904035407.4098627-2-qinyuntan@linux.alibaba.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-MS-Reactions: disallow X-ClientProxiedBy: MN0P222CA0005.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:531::8) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DS0PR12MB8502:EE_ X-MS-Office365-Filtering-Correlation-Id: 6ecab842-dca8-420d-ed9a-08df0a96a867 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|23010399003|1800799024|366016|11063799006|10067099003|4143699003|22082099003|18002099003|56012099006; X-Microsoft-Antispam-Message-Info: 5fPWWy6Qn+0YEyHNFbvrI693IvS9bvzpRBiZBsH3Izz8FlhE+SL6kC9gzIaPWRc6ByJ/COeZE/tJRYtFGjNKWAGqP4PcWC2NJJfCwJKiHvR/Z9mBdznbzmQBBzB1VtlZkzbqFMiTPXa5+eBxvf2DLv8Q9XnL4UlAOgJPoB7Zk2Atpo9c6l5beCWarnSWdV+LJq+Zah2qHn4N9sXB6th6pOA3xpICfyKebzbBdXzqxmjkSMiDbrwK2+7leKWQe42eBsCs8obkKjAZu3AiDFCz+uFPUaGENfT/SOhYW1ILJojYDadyd4yEc8FjuNg0wuC5scIbw4NNexB2kLKaLEmnEArJw5sHHiWErzS7D/nCnK8STHbP8ozzPcuweNKSY/to1nTffbu21UAztkPWmGX7/zBOrLDOYPnnE03wglU3kTRLcEa9VKQwXWGcM5eOM6vLDAcUNUs+z8y1CWIj9sLTvpd01wZo5XVQ/0bXcQxriA8eedZhblbsX/vdBjlpSwQzJW+1KwBlZKKw8zDQiaY1gohmsQvBYXhLcHlCU3xBwiKycIPNyIbpVKEqB6zG0Wsexk7D3Mwau73psLE5MZXE9iOibIUolVDzqt5kQwSSMXIJqSSNyTtr+LZBkZoZpTj8wVYpHwg+ASW52vJhiImCit+J+6iQQG1Rw4ChAfbOc6g= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(23010399003)(1800799024)(366016)(11063799006)(10067099003)(4143699003)(22082099003)(18002099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dHU4ejVEZHpQR0M4TGJjci9NWWF5MVRlUlVHaTZ5L0tEWDhVM3crVWtzTzg5?= =?utf-8?B?dW5IemNDd0MxZ3N4ZWg0Q3djY0h3Wi8xN1lmZS9lOWFzcy80NUthbU04aDAv?= =?utf-8?B?WnF4dWk1ZFh5RnByUHpCMndkemsyelpyUjhnTHVGa1RPdkVWUkV6YnRubVdD?= =?utf-8?B?bHg0cmUyOStmSVN0cGhIOC9qZFNFcXZKZkwxSm41Y1lLbHNRMDR2bmJoa0tM?= =?utf-8?B?dWVHT1k5M2hrVTk3NmFzaTl2akYvV05SRkNpYXorQzhWdVpiczU4SkZyN3pn?= =?utf-8?B?NlBYeGdmNW01dTZKSmZLYUtaYTFGMEFmRUp4NitHSTUxWk0wY09kNzlFYmIw?= =?utf-8?B?Mk1BdUZ4K2gvMTB4S2NIVCt3TW1pRlJINjlxTWwyS2ZGaEdwdFBRcFQ2emxP?= =?utf-8?B?SzBObTdiS2lrQitJMjljcnQxNVZkd08xRkdsT0lQTklvZEdPR3Vub0t6NDVa?= =?utf-8?B?ektNTWNGVkplV3dPNGY2eUJUcHc2MUZrQ1Q1cXhQcWxZZTY2QU5ZQXloTGd2?= =?utf-8?B?UTBLRkorOUR1UlM4QkRKSWFvbHA4M1paaE1iSkQ4bEs1NWQyb1NYd2R1RzZS?= =?utf-8?B?QVN0azBkMitkTHRERHQ5WFBtU1M2WVh4czFzTzBpWVhrY0t4NFMwc1k0RTNH?= =?utf-8?B?RHJGbzl0ZFVuL21ia0JGMUlNcU44TzlTR2RRM2ZXNXRZWCtLcWdXa3pZSnUw?= =?utf-8?B?SDFNL3phTE1seG9lTlhJbElMWG0rUzd5SWFXS2puNmhjSjl1U25SSU9nMUdZ?= =?utf-8?B?NmxjMXVWaTFuSDE2QWIvaXhSL3VJYlk3czhLZHdjS2RrTXY4ajYvL3Z2dFFy?= =?utf-8?B?cGFUaG1vaUpTcEt2WTZUVXE2UUk0K0lzM2o3ZWFPT1RSN3h5dUtjZ1BkOWlN?= =?utf-8?B?Zm9NQjY5cFNaMWExVDIyZWZ0RXgrYWdhdDhxZE5qQ0t2RHMrOHVXUDlvMkt5?= =?utf-8?B?aG5QQ0VhZm43cmpXOUVlNlFUYmRyaEs0SGtNbTRvNGZmdk5veks1ci9LTmZN?= =?utf-8?B?UDNrd0hnK1JZemxQNkNIcjZtTmdPZ3NMVmRuSDd5YXNoeEc4blQ2T3ZMcGhp?= =?utf-8?B?VGVnR1laNEdMdm5WL285Z3RpQVcwUHZLY1Q2THd2K2Q0WE9nZTdIOGt1RWFC?= =?utf-8?B?RCtWallMTUdPYTFtdHJ1eitueDFja3FzRGNNbEtGTzFjKzVsdkNMSzVuRmFu?= =?utf-8?B?dEtINk10UGpGNGViNmIvLzdDMWt4Y3FTZjJXUnlzNlh3UmFxaHhqKzFaU3Bq?= =?utf-8?B?bUVBYjFVeFNHenF3cGF6K2dZQkZtV0R1WlcvYkx3b1VYZFFzRmpTdy9VeGov?= =?utf-8?B?UUkvbW5JeHVPZWpaTFlyRWhOb2lPZFFTK3c2eHkvbFR2YWM4Yndsak1mRVls?= =?utf-8?B?M2pIUjZLWE9CcThuUDBSeUIwRzJjRHZmdnREY3VSSlcwZ3JuM1NiSjNUOExO?= =?utf-8?B?aWpjUnlVWHozZEhGdFpXaTRTaURjaWpwVTBVWGNJYjdUTWlUdVI3V2pXL2FL?= =?utf-8?B?VE8xYTY2SC9MYnNTQjJhQ3lmREpJUUhXVnZWcFZ0R0laYS9sdDdvV1R3OXNG?= =?utf-8?B?Y3F6Z2hTVGJKWnIyZGVBQWJuWm5XQ0Z5cnFBZXMyS3ZFMW9NUDVyeHRGcUdW?= =?utf-8?B?SlhxaUtqcmRVVW5WaDhLcmsrUkJPWXJ5T04rNUJFK09XQktiOTliMWVUQlIx?= =?utf-8?B?ZFhqTjhOY3hmS1JuSytGNVhBYVZMSG9UaUllRngvRzVxRS94RWhSTzMvWGpI?= =?utf-8?B?c2VTOVRva1JFbVl3ZzNuT1htSUp6MzNMa0NvOEVVOGhXcUNneGFTdkdlb1JM?= =?utf-8?B?K2lXUm1HMmI3allZc1JnQmRkeHJqQ01QVDFHaCtGdnZEdURhMkY1MnJVS2h0?= =?utf-8?B?dVlXdFlmbjRqcHdERjErSmkxbVlxK1dRRzNNNzl2MmdBN1RxZVpJNVNxN2JD?= =?utf-8?B?cHhBSDVuLzRRb3ZkMEx0VjNGR2NIOWRKMEs0dXhnWXJ0TUNlMW9hTFdmOG82?= =?utf-8?B?a3RJR3ZodUxFeCtrbUNZZjlydlJja3ZEUlZUbE11SUpKUVMrY1JiNU9HcDhN?= =?utf-8?B?UG1UYU11VzJFand4MDNYYW9iam1kQlVrQVBhK3dzTFdIajdXaXlmWmo3RkRP?= =?utf-8?B?Z3pHRTFZek5HdUl1SHJDNEtXcWo0Z2czYWxUQitvb0NQdytSaGU2aXJyekYv?= =?utf-8?B?Q01taWtxWnZsdnpaTVdiRUxkM3BoRjMyVFd4WUF3YlIyRUV3cFlrZlVLekhU?= =?utf-8?B?Ty9QckU5WXpxZjFVSGFFNjBPck81ZU1SZElqSU5tS1FqVnRaUkxSMWdMNk9z?= =?utf-8?Q?SHXXVthUdHpaaPZ8+j?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ecab842-dca8-420d-ed9a-08df0a96a867 X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2026 15:10:29.7606 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: txGp9Ck4q/vyCt0dxqJzH7h9a2mABddYFv7zcEkceM+KGB3a8WWi5gdYhQMLdxaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8502 X-Stat-Signature: zt645xngzczxydepy8b5w9ug6nm7kb34 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D33768000F X-Rspam-User: X-HE-Tag: 1788534638-457440 X-HE-Meta: U2FsdGVkX1+viEjTnwgc4pjkW/4O+no0OFWpIeJPDdmZIM6Nsx3UDWw78qV2+BFHv8XD7jggOrkFoTKuQQMA/dkb3QLY6fD61rOzajxxRMHFHDJSn4wmSF7jkD5nNZ+AON3Nb6Rn+U+qTcjU9/DggIGNScva4gXCVf2eRkx2hLk6izJ0tOJ3beVpt0JqktNtiK2/EBaRh3WrrSBQgSoSsyTVQ7/aJgtNhZ6Nzwshaixp6DtImriuaGVsJKaJ6nHvf20cm0QKTNLgeYrmCsaB4pS7wWvKZuAaYt1XwsEyh4+qKVSXgDatnD8QKWPt1jXxoihFsMN7/4ZSm2ti0R2N5zyGODRjQ1LNclVuSDbNrx4RSDO0l/1j+pYdOyNCRpFt7WMexsGOPM0WLGbE1VdIj/DDmI+XGkJ5SQcBYKFiB6/1MlnOgWU7jFLZQgddq7zCHvOyiNZstxE1Qj8/Fsxq5Xad0rgnlYpI7nJAfr6NAk3Y2Ye00k7PSYQxAa07wxGimoGxeK/3XYQi0fa2WRdGPN91IhOEr3srOemqup8d+d8OyVq7TciWOfUBLkLoCLEfigCAIYOiPQTHIybnIgrcbUqJtyheKHihJbkXwET6OWXzM+1j3zQH6tz9QjqrlnjDfVUKHyjzzQKiA6ilK/mvFmrox/QA9Uo9LM3QCiqjH6nayhptdqoWXF7p/mDxgTID0yYSqZJoC+fbXmRyXxls84Xe7msOcxsqaaJUNGnW3XW9/wN/9fY30N0M6z2AMsaRYTqC0OiDR/qYQ4Hzek2+Oa3f76J4F5HyJNg4GmemLHaPtjJwJoXCZlFwnXsqq9mjLgAGE2YB60Ilr2gcRcLYpsF9Wht7teVUGUTdNAF1I97+hsQiedHQzJ7rqxSDuw8HtxdBYXCSqimvODkYI8L+UZSv1t2M2o57jLrLlHMzqACoWU0fs4lShNCNlN4ORcNXcoAh3HQrKc4ChLru84O kGRwW1xI g+DrXMi8edXbfPw25iNUjenSk1hqHtC38GbbLLsaYxBxxCI31TpgDonYtgdCKtEzC/RJBJzI1i2EG+JcbH37zaa/FuNKDMaVpdQRBwDwvaK3djdzNTCLZbE/ZZAHDM13mA+8YjKPLOj2RPnZtD1rbY4U/GxMVMAhH3Vu52fg3NWl3W5eZdx5maqesY/m15VOkgvOYzYVicaYq87NFDJ7IjGf5AijWO5TwnToUtVa3fE2KX4nLacugAU3x+3HAWayPe0aCqEXagyWq8y2q3PNTMVMOEqeXOUYqUXnIaSURPQpWEBHlKxtSIztquU/D0/gyXIlf/lNbyIlkyGv4Fx3/SIFLHoU+OZlO1RJO5cfZ9TKu0k9lT/IERvSu+xTuF7fDdQjf3wIaR3kHSzNMmEG83xA0MweAClnJnrPK/rZqluNK7EU= Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 3 Sep 2026, at 23:54, Qinyun Tan wrote: > Anonymous THP faults happening in a kernel loop that does not return > to userspace -- the populate loop of a single mlock() call, or any > GUP-driven population -- can drive a memcg's usage from memory.high > all the way up to memory.max with zero reclaim and zero penalty > sleep. > > This defeats the containment memory.high is supposed to provide: > above high, the documented promise is that "the processes of the > cgroup are throttled and put under heavy reclaim pressure", and > userspace OOM handlers (oomd, Kubernetes) rely on the high..max > buffer as their reaction window. Only after hitting memory.max does > the non-blocking charge fail, THP fall back to 4K, and Why not force THP to fall back to 4KB when memory.high is reached? If reaching memory.high means the processes are under heavy reclaim pressure, I do not think it is reasonable to give any more THP. > folio_prealloc()'s GFP_KERNEL charge finally restore throttling -- > by which point the entire buffer has been consumed. > > memory.high is enforced at two points after a charge succeeds: > > 1. from resume_user_mode_work() on return to userspace, requested > via set_notify_resume(); > 2. synchronously in try_charge_memcg() for large overcharges, added > by commit c9afe31ec443 ("memcg: synchronously enforce memory.high > for large overcharges"), gated on gfpflags_allow_blocking(). > > A populate loop does not return to userspace between faults, so gate > 1 never runs. Gate 2 is defeated by the charge gfp: since > commit 3b3636924dfe ("mm, memcg: sync allocation and memcg charge > gfp flags for THP"), the THP fault path passes the allocation gfp > from vma_thp_gfp_mask() to mem_cgroup_charge(). With defrag=3Ddefer > that gfp is GFP_TRANSHUGE_LIGHT | __GFP_KSWAPD_RECLAIM; with the > default defrag=3Dmadvise and no MADV_HUGEPAGE it is plain > GFP_TRANSHUGE_LIGHT. Neither allows blocking. This is the right > policy for the physical allocation -- a THP is not worth direct > compaction, fall back to 4K instead -- but try_charge_memcg() also Right, why doesn=E2=80=99t memcg just turn the THP allocation into a 4KB fa= llback? > interprets it as "this context cannot sleep" and skips the > synchronous enforcement, even > though fault context sleeps just fine (it holds the mmap or per-VMA > read lock). > > Fix this in the fault paths, which know their context can sleep: > after a successful THP/mTHP charge, settle any accrued over-high > debt via mem_cgroup_handle_over_high(GFP_KERNEL). This reuses the Why a magic GFP_KERNEL? Would adding __GFP_RECLAIM to the existing gfp work= ? > existing throttling machinery (reclaim + calculate_high_delay() > penalty sleep) and is a no-op read of > current->memcg_nr_pages_over_high when there is no debt. > > Deliberately not changed: > > - The charge gfp itself is kept coupled to the allocation gfp, so the > fail-fast behaviour at memory.max (charge fails -> fall back to 4K > instead of reclaiming or OOMing for a THP) that the coupling was > introduced for is fully preserved. > > - try_charge_memcg() is not touched: gfpflags_allow_blocking() is the > only signal it has, and it must stay conservative for callers that > genuinely cannot sleep. > > The pre-existing selftest test_memcg_high_sync, added alongside the > synchronous enforcement by commit 6323ec54b450 ("selftests: memcg: > test high limit for single entry allocation"), readily reproduces > this: it mlocks 200M against memory.high=3D30M and memory.max=3D140M > with swap disabled, and expects high events with no max events. On > systems with transparent_hugepage/enabled=3Dalways it fails without > this patch -- the population bursts through to memory.max -- and > passes with it. > > Fixes: c9afe31ec443 ("memcg: synchronously enforce memory.high for large = overcharges") > Cc: > Signed-off-by: Qinyun Tan > --- > > Note for stable backports: mem_cgroup_handle_over_high() only gained > its gfp_mask argument in v6.6, from commit 9ea9cb00a82b ("mm: > memcontrol: fix GFP_NOFS recursion in memory.high enforcement"); on > older kernels the call sites take no argument. > > mm/huge_memory.c | 8 ++++++++ > mm/memory.c | 2 ++ > 2 files changed, 10 insertions(+) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index ced400f72d43..543ba4a74dc3 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -1329,6 +1329,14 @@ static struct folio *vma_alloc_anon_folio_pmd(stru= ct vm_area_struct *vma, > return NULL; > } > > + /* > + * The charge gfp encodes THP allocation policy and may not allow > + * blocking, which makes try_charge skip its synchronous memory.high > + * throttling. Fault context can sleep, so settle any over-high debt > + * here instead of letting usage grow unthrottled up to memory.max. > + */ > + mem_cgroup_handle_over_high(GFP_KERNEL); > + > if (folio_memcg_alloc_deferred(folio)) { > folio_put(folio); > count_vm_event(THP_FAULT_FALLBACK); > diff --git a/mm/memory.c b/mm/memory.c > index 8b0c2c735d3d..24cbf2a26905 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -5362,6 +5362,8 @@ static struct folio *alloc_anon_folio(struct vm_fau= lt *vmf) > folio_put(folio); > goto next; > } > + /* Same reasoning as in vma_alloc_anon_folio_pmd(). */ > + mem_cgroup_handle_over_high(GFP_KERNEL); > if (order > 1 && folio_memcg_alloc_deferred(folio)) { > folio_put(folio); > goto fallback; > --=20 > 2.55.0 Best Regards, Yan, Zi