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]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBCA0C02182 for ; Tue, 21 Jan 2025 05:22:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EAA46B0082; Tue, 21 Jan 2025 00:22:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2992B6B0083; Tue, 21 Jan 2025 00:22:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C5B16B0088; Tue, 21 Jan 2025 00:22:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DCB4C6B0082 for ; Tue, 21 Jan 2025 00:22:25 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5606C8066E for ; Tue, 21 Jan 2025 05:22:25 +0000 (UTC) X-FDA: 83030313450.15.CC3C878 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf01.hostedemail.com (Postfix) with ESMTP id DAD7040008 for ; Tue, 21 Jan 2025 05:22:21 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=EkYLZfxG; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="l/mMLNXp"; spf=pass (imf01.hostedemail.com: domain of jane.chu@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=jane.chu@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737436942; 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=GTTpvY4qOq963AiM6yUOBWT4hXyTKFpeWF0ifX3QFqc=; b=r2jFCjdvQu088raH/OjPPvJP6BfVv/UhJQw/NbrAb0CsgqHeOIK22ZphEO4la6/3Ko6cEJ 23RkcB2v/d0AjaQ/xDLb9WreFFJtWuZT5SDjR6Kbe6G7jIVCwrBkZc2b/Txoibc/STI+oM 0TuXZ1TF5iai2DMCs3vrgchiHO4c510= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1737436942; a=rsa-sha256; cv=pass; b=V2dBiWws1jInMqm57oK2HPlE+J3qLMERvZE+mRc8NiRzimTYJkHiO6TMGoFpEYPZyPrjZa z81nxBaF/zRXiuO1/n88GzbVhI2/lAIQ5xy1WJ4kzDSUVIyHjyFeKWeZooTAeormYOdqqc PJhWck7BASxPa0+MdGkHOJsjR/AN3IY= ARC-Authentication-Results: i=2; imf01.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=EkYLZfxG; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="l/mMLNXp"; spf=pass (imf01.hostedemail.com: domain of jane.chu@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=jane.chu@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50KGMwTx011483; Tue, 21 Jan 2025 05:22:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2023-11-20; bh=GTTpvY4qOq963AiM6yUOBWT4hXyTKFpeWF0ifX3QFqc=; b= EkYLZfxGffHTLx7bYCJVkHsa7B6iHGG8g8u+11PDgkdUXPY5Y8B5nR5UakxpYldA tGuBPxXTPy4iTuHS4RFmGwOSfceYk1V6q7G+TVje9lMzYDWS6C8XaxDR6aKnREoI 6ah5T6jDk3k95QLVnO06gUYUEVYLg9WSmV/RQWYZiNzQWs2dj0pt9UH06hEIsaOW pu+7LrORPzTWaOi0X0r3K1MBEmCm2NetPhNxRSgIUHYsGYtqyT4FET6GD/U0l8jh ZE03YyDg0wg+t7zCT8N+6s8C4HQlSabgY6D36kBo74laW3JokpJz+aKm2HR6eLNs um8VTFPOjT81QgZQT9IQAg== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 4485nb4ns0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jan 2025 05:22:12 +0000 (GMT) Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 50L20J1c030416; Tue, 21 Jan 2025 05:22:12 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2172.outbound.protection.outlook.com [104.47.57.172]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 44919219ba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Jan 2025 05:22:12 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Dh4pN0jf+ir66sKqhqtk+bMQ6/JTUJ5YAy3Pgcl1xUX9btCbba83F5OgJ8XxlJfSiM8Ve4OC8fMj0eKd7dNPUQ39kINBjeHbWMtn5dgz8M+2SUddjG5vpi3LdXo5r4jNXpANsrVnJDnlyZBBT0o1C4IIejW5lK/qi7bN4mL8nd5gxgG8q09I7xi3rxMgORTrr46h5ZlNk1ePagj7OjEgWXY81WDuYXZ2Uqta9wXWRsQV5fsiVE6Bf1COZCdwBNgJd/k3C2Q4NuDObddqSHQ8NFBR1pj1C+eanbI/T2t3MG3dbIfHnQ5LEFuM85I8PQU4ROvmE3IXFUJ4AWgWPBbRXg== 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=GTTpvY4qOq963AiM6yUOBWT4hXyTKFpeWF0ifX3QFqc=; b=B3lHhaDSMzCD5qV54OBA5NI5drP6Je9rEPtHa+M7iYknehvlzV2SxzWL7HGozLR9tddjiJT2uebp3Ngc8GLsbIdVhPeWnvSGdTrO0HK0hocyZ+OkAeGvKpvurekABaw13+P5zgdh0KytClVNrkV5LBUiGrdqbm2thEtr93bwxtwCVYCe0cr0TmgxkVZltxrrBCt5Ac5FBPpjft+qPnDEM+Z+oH+AAoCsYv5w/1KhBsql/RfcLMptfDmNXMWAevmIY53WoajE4IV0PmWIzU4dsMyRNcpEtKWKDBGA5eSK+52QZJryhO+izi5HpPxe+YsbtjNnD6hq3vddGsMWmN6x4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GTTpvY4qOq963AiM6yUOBWT4hXyTKFpeWF0ifX3QFqc=; b=l/mMLNXp4CDjekaavtT0PxMisYV+E0juPNiq4hL0sY1cMfneCjb4ftlTIaiYd/ZQwkCm1ehbFXjxIoIH1TSzQzWdhynuUCAqz9vKUpI3OrhhNTHIBzPLE1nDMvmTiw/1a7pcCBthHM5B3ib+gYWHhge51z10977W/K2u471GPEc= Received: from SA2PR10MB4780.namprd10.prod.outlook.com (2603:10b6:806:118::5) by BN0PR10MB5014.namprd10.prod.outlook.com (2603:10b6:408:115::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.22; Tue, 21 Jan 2025 05:22:09 +0000 Received: from SA2PR10MB4780.namprd10.prod.outlook.com ([fe80::b66:5132:4bd6:3acb]) by SA2PR10MB4780.namprd10.prod.outlook.com ([fe80::b66:5132:4bd6:3acb%7]) with mapi id 15.20.8356.020; Tue, 21 Jan 2025 05:22:09 +0000 Message-ID: <94b2028d-f42c-41c0-90a3-4938472a6f3f@oracle.com> Date: Mon, 20 Jan 2025 21:22:07 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 0/2] How HugeTLB handle HWPoison page at truncation To: Jiaqi Yan Cc: David Hildenbrand , nao.horiguchi@gmail.com, linmiaohe@huawei.com, sidhartha.kumar@oracle.com, muchun.song@linux.dev, akpm@linux-foundation.org, osalvador@suse.de, rientjes@google.com, jthoughton@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20250119180608.2132296-1-jiaqiyan@google.com> <6f97f3b6-3e7b-4ff8-8d67-ef972791cccd@redhat.com> <673b0353-ad8c-471b-8670-25d9f06d232b@oracle.com> Content-Language: en-US From: jane.chu@oracle.com In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SJ0PR03CA0030.namprd03.prod.outlook.com (2603:10b6:a03:33a::35) To SA2PR10MB4780.namprd10.prod.outlook.com (2603:10b6:806:118::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PR10MB4780:EE_|BN0PR10MB5014:EE_ X-MS-Office365-Filtering-Correlation-Id: 557ecfde-8b19-4c7f-bc5c-08dd39db8dd9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YjU5alJrd1JuY0JaYVE4bTV5ZVZveVpsenY1TlJhZHBCL3E4ZDk2ZFJTSmUw?= =?utf-8?B?WVM3Q2FyMEhOcE5VdFEvM29hL05Db1N2RXhxdkxDbEFoQUxYdHJkRjdDOGQz?= =?utf-8?B?RnNMUS9zbFRaR3lLUEhld1M1Y1h5b0JxWXN4b2FnZmVnZk8rNW5EWnpjc0ha?= =?utf-8?B?OHNFMFZPZ001UE14UC9ieHRZVTV2TjVKWnRMNDRBd2F1RzllMU9CQTdVUm9C?= =?utf-8?B?eTlqYUVpbnZvazhTNzdTdzB2WGlkTVhRKzg5bGxZQWlJVVg3eEwzc0pyOVZz?= =?utf-8?B?SkhHeDh2M0xSU1phZ0ttVlhWbU9uYTErbWRPVzdMSUphTHpReHJ3TjUwOFV3?= =?utf-8?B?aUJ3YWs4blNZcUx0RW54NU4xR2JuK1VvNWZQdnlhVkZRcjJzZ2Q1bTNseEdU?= =?utf-8?B?ZiszZ0w1OERRajNKWk5oaFRJL1lpdU13UVhVdndrNDVCd2ttRTQ5OVhKZU4y?= =?utf-8?B?WG5CUVVLbEZXWE9uTUYxNEt5UGdhOUN1STRyWU9yTURPYTlOWnQ3ZTlqRkZP?= =?utf-8?B?clJuVXNqSFZ0SWw5REsvREM2OUN2YWZWTlJDdUNXalM4aWJ5R3NHcGVnK2Fj?= =?utf-8?B?TGVuZlNqakswQTJOYm9sSkdqT0ordVJRQnZwWnVraDFiRlpaTmRKcDdMVnRT?= =?utf-8?B?MjAySjNaQXNsYXZja1BING9PVThvdXZHQWZ2UG5vMDg4NnE4K2NzRk9jME1N?= =?utf-8?B?VUpMaWZqNHRRWlZza0YwYm1ZUGhiampzc1VwWktxZUFTdzkydFBaWjZzTnNE?= =?utf-8?B?Q20xV1JTQitCa3VZcUFLbmM0dzNFdjlLakFxUTdHa0ZCQkF3NGVnZmhVZDNQ?= =?utf-8?B?Z1pyeUU0YnpEWTh6dTFIdWRvd0p2cXN6MkpBQjMzb1ZXaUM1ek9tbGlDT0pr?= =?utf-8?B?Zm84WnJ3VGZSZ00zSVJlSk1BS25UZ2pmU1NQaFE4d1liaUVVRkVUOG1PLzhq?= =?utf-8?B?cnlhQmRJdmpQQzNqZkpBaHd1d095OFVPb2I0RkFRTG5LREM3WnVHTkQzdmVS?= =?utf-8?B?dHFldGZVejA1NEcwY2hUSlpLSUwrNXVrSE1CSXhZVFBYN0pBOXBuMW9NNjAy?= =?utf-8?B?REpNdzc3TWlWaFdjcjRpRUpLcFdkNXUrdkpzSjVndmlWOXRkNVNaTlh6UGxT?= =?utf-8?B?V0N3NFZZalErRGI2UjRySjFyMGw1czlESEFrYlZEdWZmSkJyTjlwT0FMbWZC?= =?utf-8?B?ZjRVU2ZaYnBnSzZsU3dSN2ZUVVl6RnRnUTIrSUR6K01tSWJTM1ZqdVhTdXdN?= =?utf-8?B?RHlpWVpQcG1YVjd3S25kM2habFNORmg3R0MzdkIvZWZGSzBSVDduNUg3VXVV?= =?utf-8?B?NlhlVHNiV1hGa0VORGlsTTY1NW9DajJuMHZOSVZDSkVIR0czV0svQUVrVXpw?= =?utf-8?B?N0V4WEptWXdRdXhZUFpkSW1DV1hFdHNScTU1UVZVY05EZHB1NFc5U1pFOXFK?= =?utf-8?B?U04vY2xSeFJrTUVhVWRGVU5qM2l4cFQrNkJkaEN4R3BYOUVlMTh4Y252MXQx?= =?utf-8?B?ZytpRTRRem90dlIwMTFuaWZhR2RXekU4cTlWVDZLRC9scks5TkFqbDZiYjNr?= =?utf-8?B?ZEgzd0M4Nk9ZKytrK0tTZUdmK0NjMDZFNnR5ZFpDQmxpS25iT0E5c3ZSQ1ZF?= =?utf-8?B?RXNneWdSWTY5M3Y5RmJZTWZNWTlLS0dFVWx6THV0RmpxQkR3ZTlNbHh3d1FS?= =?utf-8?B?aUZ2NzkyeXM0Z0hlSUpKb25aNU95Sit1TnNVcEI4cG9TY3AzYXRlN21BV3hm?= =?utf-8?B?RWVrQzlud3JwcjJ0d2xUUHJxQ3k3ZzZ3SlFNMHdsTWM4MlM1QTBFMzd4Mk1L?= =?utf-8?B?QkliekJmNDlvVjhjc0oyNnNNT1BSVXBVTFNnV1J4NkRIbDlHeHNDMDhQYjlL?= =?utf-8?Q?6aQdH2EYWKT2a?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA2PR10MB4780.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c1JOZit5Z3g2dFh1NUNqRWp3YS9oaC9iUUVSSStGU2JnTVYyS3pUY2Vnb1FJ?= =?utf-8?B?Wks0SlgxejN2QWlFYjRqY3B0azZNTDVHdE1JcW1xZ0FCNHJjNEJvZXN1THMx?= =?utf-8?B?SDlCWUo4QWNtUTdXemQzbnI4OXZjVHRjWDlJeEVpVkpOeUhvQk9ISzdaYmRw?= =?utf-8?B?d3NpTHRsZkpTU3kxTEFKQVFhUUZuUlVvMGdxYkRuTzhWbWVzNEpzVk92SFRO?= =?utf-8?B?alFoUWpPekZGWUdmR3JDTC9XckRzV0NvTCtYNlV4SkNnSlV1MHF3V2N0OHdt?= =?utf-8?B?bzBycjlBOHljS0Z0bFNZUU05bXBrbzJoYjRPaFE5NStTRG5keVBocG5XamxT?= =?utf-8?B?aFVCdERtckNpeEwwckxZOEg5Tm5KbElQRWh3djViNTRabFFHVG0yQUJSK0VC?= =?utf-8?B?Qk1WdjE0Nm9FdlcwWVRhME9JY2lYbGlMNFhZV3NxWDBNZkZoZjNKMjhVK296?= =?utf-8?B?dkdjdkFSMWM1UVFJUUkwTEwraVlPNDJOUStBRXBHOTlCM1BOLzBadkJZa0Ry?= =?utf-8?B?V3pYdk8waWFGUEFMemM2NXF6Z0Z3SjM3bnN2NGM3eEtTSERtTzU5MS84cTlK?= =?utf-8?B?WmJZbnczaGhGdStZVEZUQUJ1N2x3NVloUVdVRUsyQ0l5QWhVS2tBTURDOHRS?= =?utf-8?B?N21td3dyQ2E4TG9aYlVjTG5oZEpvMEUzME9DNFdKZmt6c1ZYNTZmRDZWb1kr?= =?utf-8?B?MzZodW1veHdJVDViN1VuRUs3Qk94emVxeFJqK3gycGFseWFBbHpWQmFOT2wv?= =?utf-8?B?UGl5SzZraWx3OGMzVk9QdVFNck02T1RQc1JvUWUzZUllWHA1ZTdhOGZCbVlS?= =?utf-8?B?TWZrejNsWC9GWjNHWk5VM2pMN0dyYXl6RlFVZW9ZdStJWlJaZnZycXVwd1M5?= =?utf-8?B?MWRZZjNIODZZZEk5djdEaVVHRDhyRjYyWFJwcDBFa2F4L05GaHhybVZ3U0hr?= =?utf-8?B?ZFFjYU55L3BGaVpqWERUVzNuakhJVFNPMXpqdUx5M0hoMitDYXZsa00weERE?= =?utf-8?B?b3YxdUxaNjBuUDNvTURnd3RQaXR3cnNJdzQzUEU5dFdvTEhFcmJCRWpxdWtP?= =?utf-8?B?eUNybmNtc1ZFNTE0d05mRWRscjRtY3RlQUtQVE1Yb00weEZteE5zZ3YrczlK?= =?utf-8?B?cVJYNFhQV1Y5Q0JhUVJXNXY3TE9XZUZlTVBuSEs1NUNYMUZMTVNCbkVXRmhJ?= =?utf-8?B?dUsyVmxWQXROMXBZWUZzbzRaTHhOcTVpSHU3ZHZRV2RrTXV5MnlIREVSRElD?= =?utf-8?B?M2VzdXNCNmo0OGE1WVdPSDkxZmcxaHVhWkkxaEdLNzhXbm41andidnVoVDBw?= =?utf-8?B?SHYxWm5PbDlzNi9rZ0lvb21pMmoydi9ENWkrcVF1cDA2YzJKZzVUMHpqcnJ5?= =?utf-8?B?UFdtb2NQWjhNSVQ5YWd6RTVRTkl2d1VyQkRmOWl4NnU3VVpianFuMjFMV0ZL?= =?utf-8?B?OWR4d2ZST0NZa3pWcTVFMUVjSDhycDJpZ0ZyT0NydnMvR0tua1Zha1lYSm16?= =?utf-8?B?aHZXV09JNzg3TmhwZW4xYlJOQ3c5UjZKY1Q3TFBqYk83WkRtYW1tUk5jMVJX?= =?utf-8?B?ckIyMFJNYnlnNUtoTVdlREdHdUVtMjZUWmhUeStQMEg0NGc5U2VSN21Fc29U?= =?utf-8?B?RnZuSmhWRG9kRGFtTi9pVSsvcnpiUUpIS1lBWnN1WWZvU1J0OHBBVEp4MmpH?= =?utf-8?B?SGFGN2pnWGxJYWJSa2VnUHM4bEM4aEpBb21rTElzcEFiMW1GQnZxR3dpdm5r?= =?utf-8?B?U0NyTlZwUUdWNTZrbWp2and3RDRXWTJ2UWdiMW4zZnJIV0NBSHArbFUxYy9T?= =?utf-8?B?TjBsKzcyVFQ2WDcyN2F6SG5nN2tHL2k4dzYzS2thZUZaalAyOGFZSXl2Q3ZZ?= =?utf-8?B?N0U4S0lyQTJIUG1YMUdsWjdUWlRCdHhZYVhBS2lJWWVMZmZkMm1UUEJQNUdY?= =?utf-8?B?U1VuZUpkTEpBbURPUS9FUHl5QU9ydkcrQUZzVUVTSkY1SzFzWlEvVm1zbm52?= =?utf-8?B?cHk2ZEdMbDhxaWRCR0VsSkMvVTI5cTZyQnRuZnJuZTgxdkxjdlFhRklJTC9K?= =?utf-8?B?SHh0VnRCVmYyTzNtb1dBeFA4bUx1cXpFUEY5NGh2dDRRMzZJV2M1SEJsaWtQ?= =?utf-8?Q?3IY7Vv8LbLcRGnZaFeuvdmnV0?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: K/Jy7cDQLEKHv+cE9hy8e/A3Be2AjNoyg908uGJTxrqw+YwdwxLem3UqZQbgG+QAI6Edcmrm8MrXzQOF/sGM4g610KY2nGprdkvF+wIMeO7IB5pcnF97DZXIdQRztY2GTgtIDQRsmC5lmMCnk+OzcVGbPhtotik2T0YCDibJ4gOiiYWEIhtPkbyhit0T0MUo1erBwJGJcQki6ktyWQ7NIF765IDSNn5hggHJgbmtx1erWK3JvYoqasQ1LQH+OaYhTMiyiGLqVAZ+P+RczVkkQFVNglrjfzrGYIKfDHTvA3JIGzsAAoN3FPfawFvbHvaY0WstwTQFG0IyDlMRY5l7N2hX44luvG2Morbv/e7Qck+aMeJFyN0WBd34OvLFJvUCmSjtwmcfdfpv2Fd5+6VMgxVy8j1LmaDFDCU8uiKZidU41pBIOhcuA53ynXmc5Lw/OBcHrPg9Cyyrf57WyY7+2AjkUEdnowiN4KcmoeBYRvXPSX3yxagltjrZvdy+YoXGPkr9aIyx9/YdqOvjVaG/kTU909tU7t24sud120NLarVCzwBRgGI6VDIIS7jGpphV2E4In82w4/NANBfJCdSSpYSmoj4bhBDJX2huXN8utTM= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 557ecfde-8b19-4c7f-bc5c-08dd39db8dd9 X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4780.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jan 2025 05:22:09.8238 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UTS8dhcM3yqfcKbKgF+UfQ0327SAW2URqu6XKDs1gyPojZ/58MXtKnYyEDhLeU3eXbH04h/GIjD3V/rKqaBC0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5014 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-21_02,2025-01-20_03,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501210041 X-Proofpoint-GUID: nze1NFyLbksbKHWWUyODKpRkTkbYST3C X-Proofpoint-ORIG-GUID: nze1NFyLbksbKHWWUyODKpRkTkbYST3C X-Stat-Signature: kwe6ussa37y13bbyhiuqagoiddkzatpm X-Rspam-User: X-Rspamd-Queue-Id: DAD7040008 X-Rspamd-Server: rspam03 X-HE-Tag: 1737436941-156261 X-HE-Meta: U2FsdGVkX1/VF8q0QM46Iz9o3WZf2UuyXyfF+8cTGCfSEasqh63BadtG26j8UXGAIo8YGuPotRXtXgDAKmH0UWLAbxvmieOQSi2uEKGDFkZnIMDM+uxLsnXk030Y++1n9Qgy6tkccZwkrPlE4/8ZpXmRfkzoCeLIlx5MELG/zKZZynLgZ4z0ZTdeCW9Ish523++nXHj2iNRUaIIC/wxgB1OIkLk1vzppRo5sVthiswHIvxi8WAT09MLXYNxl9xFr2bA5r8tenfVKzhKoODLMpAe59147DSHiulCByAkmIx6ZD8GWyAFxGqPWRXzbksq8JddT3cR9CTJ5hqJ+Bijfqr+UIeJNYO3y9vbEaCnSFa0N/qIkUl2T785k/7GKm65W5TW1LZQ1tP1GhDvrlIVfvTcxZKiYCZ1hVqVhdrSSFLtwPFhkim5j8J/sqIZ8oIFBdVrdm9O3rS9PrUb4XX7wEUt639qMc0aKlL7cwxIJ697NFcBWUMmKajArptIRC9yHbQf8h1YxH2F5SfWOVzJnTlwZbZbdqBxTmorzN9MvwsfZaxtBBXJUDcku4+ckajKXC7C36EaspxCcR2TF27DfwN9TtHpvKYwyw2NlIH81tDMvOCtQgASpFkA69NWEJjvLoQOOhOpbUgbTvgAPvp6yDDOMbUmVsmKbJEvhUx1zQUSBIVUyha24NBnCileRWqHp4N7ZN3gj+R+j6ZL9mmEByrxxrLi3+T7h3031Q6XuTrXPXk5Jes/N0OFuyj1OmO9xiAWUr1DWpLrKcqVrnVFSgJyclrWDGiP+Zr5jVPlZuCdMA9C6/7ASrdbu4JeQIqG9mO3fFfmMMNMDGXxvkyZBv30Rd2ewXq36LQ9ZVGLyFwbJEzu2kmlsSrU90zIEkhYCm3/mazuaak3pXub9uCJYVg18j5JKG8gGyigaLeZpKwIhqxFRbOAb9oWTnyXSecfU64pjL0dNU6mWL4ntRXP mP2TXqji frWFHiUeg4lS0aSSkh7EwEJJQCjwBJtHzZ0VSuJBQ1NGqHBwErnqG7f/6KL2xUFvuydQEbQ4K3snYD1o1/Z7KJxQrB5h2CnvauTUr7MAWY8SOzs+3c1sqd0bAd/Jei0p3Naje4l5v1mGiRnlZLychzGYjsHMz4U4lFRNT2madZljFhgSU7jEG/RPWSrbwLc0BCCZ3vqxRcaA2DAZjcgQrZiA5ccfd3Znr/IvopJvAjtGcOb2+1SKs5L/kk2dYptwAfPFfvHC8/RiDpcgCH9NFTdg5lVySrAIpIN9D556+c2/dP6e0b+v2gS4eiRsXJdZ1jJdr3gXyxlWiq/M4c5sXPS3g7rbMWGUd/qcolH851ble4khe97OSf6a2j+dq0KvVTEKrK48HuhH5KSy8jB0lehFA3pa6fx+wDIvCE6BTOJbG7e0/cEhAItKdIMqBw1bwcHDh6UuvNII/TFtHg5cvVpnar+meveOiJGoljs/T2PoDc7xtHCDov/VvXZSIe4kgcv2XNvzsPT7bGGIfmDTs6H3uMKHiiFRWhZ9HHRMDXNJKQPw3NpOeRjMFeFYVcYhGd3oRyWfj4tPH3AVAGis2j+Ahw0E9BMmGwJGgovGwTbvcQZ9fhb+eSLHnxkpuH+YwgBTLkKG3uytIwVbLBJVQd+lHOoNXPm5utYvOBlcpPN1UGOdaYrwkUx4uQflaUX329mprJ/ClJD49qRZlvRNIvbYdYczW2MYH8od3 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 1/20/2025 9:08 PM, Jiaqi Yan wrote: > On Mon, Jan 20, 2025 at 9:01 PM wrote: >> >> On 1/20/2025 5:21 PM, Jiaqi Yan wrote: >>> On Mon, Jan 20, 2025 at 2:59 AM David Hildenbrand wrote: >>>> On 19.01.25 19:06, Jiaqi Yan wrote: >>>>> While I was working on userspace MFR via memfd [1], I spend some time to >>>>> understand what current kernel does when a HugeTLB-backing memfd is >>>>> truncated. My expectation is, if there is a HWPoison HugeTLB folio >>>>> mapped via the memfd to userspace, it will be unmapped right away but >>>>> still be kept in page cache [2]; however when the memfd is truncated to >>>>> zero or after the memfd is closed, kernel should dissolve the HWPoison >>>>> folio in the page cache, and free only the clean raw pages to buddy >>>>> allocator, excluding the poisoned raw page. >>>>> >>>>> So I wrote a hugetlb-mfr-base.c selftest and expect >>>>> 0. say nr_hugepages initially is 64 as system configuration. >>>>> 1. after MADV_HWPOISON, nr_hugepages should still be 64 as we kept even >>>>> HWPoison huge folio in page cache. free_hugepages should be >>>>> nr_hugepages minus whatever the amount in use. >>>>> 2. after truncated memfd to zero, nr_hugepages should reduced to 63 as >>>>> kernel dissolved and freed the HWPoison huge folio. free_hugepages >>>>> should also be 63. >>>>> >>>>> However, when testing at the head of mm-stable commit 2877a83e4a0a >>>>> ("mm/hugetlb: use folio->lru int demote_free_hugetlb_folios()"), I found >>>>> although free_hugepages is reduced to 63, nr_hugepages is not reduced >>>>> and stay at 64. >>>>> >>>>> Is my expectation outdated? Or is this some kind of bug? >>>>> >>>>> I assume this is a bug and then digged a little bit more. It seems there >>>>> are two issues, or two things I don't really understand. >>>>> >>>>> 1. During try_memory_failure_hugetlb, we should increased the target >>>>> in-use folio's refcount via get_hwpoison_hugetlb_folio. However, >>>>> until the end of try_memory_failure_hugetlb, this refcout is not put. >>>>> I can make sense of this given we keep in-use huge folio in page >>>>> cache. >>>> Isn't the general rule that hwpoisoned folios have a raised refcount >>>> such that they won't get freed + reused? At least that's how the buddy >>>> deals with them, and I suspect also hugetlb? >>> Thanks, David. >>> >>> I see, so it is expected that the _entire_ huge folio will always have >>> at least a refcount of 1, even when the folio can become "free". >>> >>> For *free* huge folio, try_memory_failure_hugetlb dissolves it and >>> frees the clean pages (a lot) to the buddy allocator. This made me >>> think the same thing will happen for *in-use* huge folio _eventually_ >>> (i.e. somehow the refcount due to HWPoison can be put). I feel this is >>> a little bit unfortunate for the clean pages, but if it is what it is, >>> that's fair as it is not a bug. >> Agreed with David. For *in use* hugetlb pages, including unused shmget >> pages, hugetlb shouldn't dissvolve the page, not until an explicit freeing action is taken like >> RMID and echo 0 > nr_hugepages. > To clarify myself, I am not asking memory-failure.c to dissolve the > hugepage at the time it is in-use, but rather when it becomes free > (truncated or process exited). Understood, a free hugetlb page in the pool should have refcount 1 though. -jane > >> -jane >> >>>>> [ 1069.320976] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2780000 >>>>> [ 1069.320978] head: order:18 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 >>>>> [ 1069.320980] flags: 0x400000000100044(referenced|head|hwpoison|node=0|zone=1) >>>>> [ 1069.320982] page_type: f4(hugetlb) >>>>> [ 1069.320984] raw: 0400000000100044 ffffffff8760bbc8 ffffffff8760bbc8 0000000000000000 >>>>> [ 1069.320985] raw: 0000000000000000 0000000000000000 00000001f4000000 0000000000000000 >>>>> [ 1069.320987] head: 0400000000100044 ffffffff8760bbc8 ffffffff8760bbc8 0000000000000000 >>>>> [ 1069.320988] head: 0000000000000000 0000000000000000 00000001f4000000 0000000000000000 >>>>> [ 1069.320990] head: 0400000000000012 ffffdd53de000001 ffffffffffffffff 0000000000000000 >>>>> [ 1069.320991] head: 0000000000040000 0000000000000000 00000000ffffffff 0000000000000000 >>>>> [ 1069.320992] page dumped because: track hwpoison folio's ref >>>>> >>>>> 2. Even if folio's refcount do drop to zero and we get into >>>>> free_huge_folio, it is not clear to me which part of free_huge_folio >>>>> is handling the case that folio is HWPoison. In my test what I >>>>> observed is that evantually the folio is enqueue_hugetlb_folio()-ed. >>>> How would we get a refcount of 0 if we assume the raised refcount on a >>>> hwpoisoned hugetlb folio? >>>> >>>> I'm probably missing something: are you saying that you can trigger a >>>> hwpoisoned hugetlb folio to get reallocated again, in upstream code? >>> No, I think it is just my misunderstanding. From what you said, the >>> expectation of HWPoison hugetlb folio is just it won't get reallocated >>> again, which is true. >>> >>> My (wrong) expectation is, in addition to the "won't reallocated >>> again" part, some (large) portion of the huge folio will be freed to >>> the buddy allocator. On the other hand, is it something worth having / >>> improving? (1G - some_single_digit * 4KB) seems to be valuable to the >>> system, though they are all 4K. #1 and #2 above are then what needs to >>> be done if the improvement is worth chasing. >>> >>>> -- >>>> Cheers, >>>> >>>> David / dhildenb >>>>