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 588BAC25B75 for ; Thu, 30 May 2024 01:51:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4ECF6B0096; Wed, 29 May 2024 21:51:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFE7E6B0098; Wed, 29 May 2024 21:51:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 950376B0099; Wed, 29 May 2024 21:51:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6FAB46B0096 for ; Wed, 29 May 2024 21:51:34 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E7A87A21A5 for ; Thu, 30 May 2024 01:51:33 +0000 (UTC) X-FDA: 82173385266.01.04E921F Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2065.outbound.protection.outlook.com [40.107.92.65]) by imf01.hostedemail.com (Postfix) with ESMTP id 1CA1340006 for ; Thu, 30 May 2024 01:51:30 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=rGgwyZhQ; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf01.hostedemail.com: domain of ziy@nvidia.com designates 40.107.92.65 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=1717033891; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9Jcbxv/NVGwcfBE5CJ0ejKlT28QsyjSA1+j+7fJllkw=; b=aOgis7HiL+0eN4HRbA47EoF/DIe1qVyukoNtmPa6mDGUGANZADxYw10V9OTYfzebKBgvE1 rtDAIYpI+HmRAlh0GhFjnOx+Q0HJWPiigsWA+hzK8LiS7STLXsU25L8JB7xGO6oeIWx731 olqeXnePOXDM+Jsa70eBuEQZ+HQyazI= ARC-Authentication-Results: i=2; imf01.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=rGgwyZhQ; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf01.hostedemail.com: domain of ziy@nvidia.com designates 40.107.92.65 as permitted sender) smtp.mailfrom=ziy@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1717033891; a=rsa-sha256; cv=pass; b=sy5J7+Rb70RPh0cFr2oYjpJS7MH5bRRU3hn35YGED4RSicljJLse/ulzo8ZeJawltZr0zS 9o6+UCWAYuWS1sZQCRStM499NR+fvmUA/Ea6lPTkv5CQ0LnjjVWbXyxFc4sxZFrQA5Sp5v yo1BYemJTpeWxFH/le6LS62qmIrfgt0= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iE4IPbCBnrC/d+4I21OJQO8J+y0sunkDn0yej3GOKhkZhxL2KpevruG1EMESgmdSgDM9jVa6S92d8/8iHvNq62COH/ZXQa/dW2j0UeOe0ofZyusRYiF/i7bRBsG+RC61xmOh5MYWXW9S4o862S8qv0srzbdws4dGzYkfSpHkHG26L594/SSKSyR1seU7E0XpKdMxD18oBOCtmDHqce8/fw1EolNWk5L4WyuwHs++FjLDrieSiBHRoYoZjhj9jnRHZ7DRzZgA2nHbMpWgEFsDXRwV+w70aXxxmw5P0RBxyNvWPoDyF1pyU9AO1DhI/WFIF8B8tGbXBFUf8r/u3Q5hpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=9Jcbxv/NVGwcfBE5CJ0ejKlT28QsyjSA1+j+7fJllkw=; b=lXbLbq1idWMaUZid+adVZtRBRKP8YVpYMsmCxKDnglwf7/y92XxCAUeXNm9ThxhL/0EhwmIk1ST8vfFxKO8R4BQrLofpVTIOlEuFRUBQj+GNsJyUaFmuUmxESD5D6j/nIrZI4lt7Fxmrtf76lotlBND9lylSmYWzzs3rJF2uHN4SWoW2z4gPuSeTsLsbnWfh3YmrmJMsKy/ddWyDMPf7qOMx+JhXd8ZTv6QyGX/dyTFJu5jLpknRebEV/wJwOdPac3RmT+eryJwkPz4iJFdOQxRT4iNV9kKu5iaif2yEq9Fjw6vSJO2ZXiyIzKfm38Fyrql2oZv7XpuVp3aPoKPnLw== 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=9Jcbxv/NVGwcfBE5CJ0ejKlT28QsyjSA1+j+7fJllkw=; b=rGgwyZhQPKtmiTPCj0pM01Fx18NHr/UQaoJxjU1uBnd/7wDyzxxpsv2vId3sFrcwhKtSaXNGNV/qecpTN02qcQZ7qmWiNiUeR6gtMsNcfAvgziEQLWGcd4OQuMrZh84C8fhuh5RiTTZ47uxaMOdAJk7Z8yYhNs5RZu92ViarX0713w6jcFXacN/8txdehQqZqIBK2znuNG/pZV0r5TD0IZHtaJUWF4sjwhJ55DLd0JEtmSiqj0eJGsRRC5R6XOJp6iACN/1JTMYcPrrchklvkFmWHdRe3w3ektlwqakGx9IV0dnwuGu1stWjBA6ZJZH7qE6eVe/xwIEDQl+SFuL/ow== Received: from DS7PR12MB5744.namprd12.prod.outlook.com (2603:10b6:8:73::18) by BL3PR12MB6476.namprd12.prod.outlook.com (2603:10b6:208:3bc::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.33; Thu, 30 May 2024 01:51:27 +0000 Received: from DS7PR12MB5744.namprd12.prod.outlook.com ([fe80::f018:13a9:e165:6b7e]) by DS7PR12MB5744.namprd12.prod.outlook.com ([fe80::f018:13a9:e165:6b7e%5]) with mapi id 15.20.7611.030; Thu, 30 May 2024 01:51:26 +0000 From: Zi Yan To: Johannes Weiner Cc: Christoph Hellwig , Andy Shevchenko , Baolin Wang , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Mel Gorman Subject: Re: page type is 3, passed migratetype is 1 (nr=512) Date: Wed, 29 May 2024 21:51:24 -0400 X-Mailer: MailMate (1.14r6030) Message-ID: <1C60A8DB-8DB2-44C7-920C-D15AF19F57D7@nvidia.com> In-Reply-To: <20240530010419.GA1132939@cmpxchg.org> References: <20240528164756.GA2820@cmpxchg.org> <20240529162830.GA1049743@cmpxchg.org> <20240530010419.GA1132939@cmpxchg.org> Content-Type: multipart/signed; boundary="=_MailMate_AB4EA8AF-C5EB-459A-BC64-00B2CF8AAC5E_="; micalg=pgp-sha512; protocol="application/pgp-signature" X-ClientProxiedBy: BL0PR0102CA0029.prod.exchangelabs.com (2603:10b6:207:18::42) To DS7PR12MB5744.namprd12.prod.outlook.com (2603:10b6:8:73::18) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR12MB5744:EE_|BL3PR12MB6476:EE_ X-MS-Office365-Filtering-Correlation-Id: 1c216ce6-77cc-4aff-a953-08dc804b0484 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|366007|1800799015|376005; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?mSkXltKD1ZzeBIgmgy6Y3FFbTMRq16kIIXzHRDRIfi7ciimNLZQQxI/gA4b1?= =?us-ascii?Q?0NXy/CS/pyIsgqVKETa0Lbf1ecG/EHRi6mS5bgsiUI705FNRN8Y26s3e/zaU?= =?us-ascii?Q?OyR3H2UX4FdCnjLJFN2hBo8tTzwWygQcho6NkgKu5N34LtcelyO2CKuJkw0F?= =?us-ascii?Q?DQIcxTeQ4fJ0T4YpALe6CcVBtKRcMIpDJiHw9U12Gp4YoMv6tlFa+ciFnBF2?= =?us-ascii?Q?8mFdGm7LCT/aW6jCUePy8gzwHZObBTZDNT+3MVCurd39Jr/3dC9406cNuzh3?= =?us-ascii?Q?Jv8gnRCfSRV4A6SVLfRpmK8diHtiojLK0r4DYm9cIkHJ5JjOlZ27vFizT2Tt?= =?us-ascii?Q?rFpUZ/grtXfH3aN44qlfDgepDnG4SafPD/eGn+UwFJG4FsGTdVulB9mXkTTH?= =?us-ascii?Q?/vqLbnhJ7uNmSpwXi+N1g+U4L29RnBarRJq7j0SSWE9ckZDuG9acrfH3PU8c?= =?us-ascii?Q?MQfk2PiyagoyZ77E/H4euvckjtsDZChhIOcgt3AVuFPUNB7zMzR+V+Vd0Fbq?= =?us-ascii?Q?gThO3bgsO3s/MEHUSQrClgANf6LnEd+aQpuoKlmf4TACfSCZNm5Hwmt8ZEzV?= =?us-ascii?Q?m3DAFh7kJNJ5nSC6Q81142mTdqtI1MZogzJeEXJsdwAOIbHOJk0h0NfIjMg7?= =?us-ascii?Q?xEE2AbyQ2e1rU1JYSeJnfFTKG7cGItnJMTPg2UsnRll+95MNyAr4FtFBr/oX?= =?us-ascii?Q?3qTTr+1O4/Y9j8IZ1KymhHOOazg59Sp8VIUvM9+XTzWdZ61iePRj6MYoWXPW?= =?us-ascii?Q?W85MJa1NIQjzMaC/pwmJ6rVlAg5hKKEFeakjBSTkYpKaKqbaKawNOFKytFXW?= =?us-ascii?Q?+YbFA/M68/dwYgmFxvfWU2qXWi+0QIAI/Pz3iKX/jYmXOo/OcFj3dXld+hBx?= =?us-ascii?Q?ZMMT7sbZ0EqBt5+L9hV2bcdcBpIzujrkRqihoZytWL7i9YPIIrDLJue3Wnwp?= =?us-ascii?Q?2GqxMJtBgMh2PG4xc2aZpYBhvew9bc0W8Hqn0kgNJIKcPZgoedF159l2nKTn?= =?us-ascii?Q?n7VGhMg8oc6VbLPC+iJZa5SPbc7WrUzVw2d6vHk17lq3IIx5AZW3GdZ+rSAn?= =?us-ascii?Q?Lwo+9EWsqVkQmBltFLazxA3m78LEAZtW+EQjGUPJ+JQopkfjVxOYgnW0rVRa?= =?us-ascii?Q?pwJADW/qN41ir/SNJIL6RqTe7LtIAYyIkVZvu886wKHlIiAKsNsQkuZv9dju?= =?us-ascii?Q?pRUN2pQgWowUt5ES0SsV+rhblCaCceR72cQA/XvZyaKNnvPu2n5FcLUjcljU?= =?us-ascii?Q?CgFEa4QxohEGeY6XE6ymePJksD+1K3qUN91SUvdY2g=3D=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR12MB5744.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366007)(1800799015)(376005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KORWwxFM8RbdOC+dUzE1mHt6fQqUDsnPV9u7rBfwZgC0p/e7VCr+ulBytUgd?= =?us-ascii?Q?wva344OS0wO00QUKBGZVxxioYs99Va5XGm1KqXaWV6Lkhy7YNaMpbLm099Wq?= =?us-ascii?Q?v2mslvmZAiVqYj/mubYhOg5zHZ3LFFILM/xunOdD1bNYbvl/BCY6Qivpy1pd?= =?us-ascii?Q?x4RaVX2rB7uR5Qk9DpNLl2LQ8U9oNMdTVgADcAVuH/KL4UxZz/nWLVClOisX?= =?us-ascii?Q?tIG7emRe/KaBFjNQHWFJ3T+zeOX0tan8ixBEbj+S//INX2vd1jurJ+3OGLNF?= =?us-ascii?Q?rNyp+b79VAMFAJK/b0CRo/f0z6W39IOWxc4BCeAk54bJr8GCvTdfE/bJ5co5?= =?us-ascii?Q?sPiwtdlZhLkscV2xH8y8RdmOZU4HxnXusvXm/ZfOccKqgEKq5DMOOCuc68vp?= =?us-ascii?Q?HD/3QjkkNFQ9h6gU2pHcke/UcEO5nB/JKlPsAuihTgHvBZrSHo8grxFkxNI8?= =?us-ascii?Q?T5g7y+Qi8taZYDJPZUeLAaakQTx4o/o9fSwQ7SGGjKCFe9lP59z6lhL1RsmF?= =?us-ascii?Q?b+k8IxdGLVJrUfoW98xohGGu9cIbp+neePfVzt/9QqcTfjTVUzzBVV0CQDyD?= =?us-ascii?Q?cXmbn6BzQCs/xqcVyOBtx+QtnCmFQc3wX9XPsfJWetB2ABeoc4XDbifpspRR?= =?us-ascii?Q?3M+ddXQeCOZq9e0X2jUo/RFD4yQ7OH72PX9AbAZzdnA709BGEteqiUkysgEV?= =?us-ascii?Q?JCNjclz3gyaxM4sY/JFjbZPSaaSIt54Ktjh6u5F4TvxsQ3I2K1FyiZVbdVmL?= =?us-ascii?Q?cp0z/lZnLH9dWehWmjXN3AKsXioKkxaWmx/9oSTbdz6jHtiG4deC16PJopiF?= =?us-ascii?Q?QJ0/VcQSQg8KB7R31RZ/TlThMbNcE1arsCGfPC2erMJaJepzLe6MOou/nj5V?= =?us-ascii?Q?IW6R10XccZh1i2U6YZQCKu+94WIpNwBWSc8bLd4DOen2J7GhRZf0R35J9VGb?= =?us-ascii?Q?6QmS/LrmQxXrKuooxLTlduPHTm9+/I4fe/OISdlWJVWPl8arXU/O+4DWVqbt?= =?us-ascii?Q?wdsLxA297JzQhkjBrSwAfSy/o5Ka9mIUb9HMH7zSGULA+oLErrfILfRj+7En?= =?us-ascii?Q?nyXE7pqqMQHj79d7C5zvg5YljmI+uwWojv8YPCobW3SWagRDZ++RLC1XZ7Ic?= =?us-ascii?Q?+fA5Wub1zMmnQIc+ZewGtvjzuVTLqltAwpyehgzKFd6T5awBhJLOwYz6N7ag?= =?us-ascii?Q?oQGpfw9FdmUXq9kAEwlq6YR+g5HFKrWu+QiX/5add+9FC/16V2B/joOCZyzJ?= =?us-ascii?Q?B5tOM0a85GgvUYTbVpSMqQrgKsY01ZeboKWaBHBqr0MvXvntOFzmvcfylD/S?= =?us-ascii?Q?7akjFkVAqLNxvOv4KKeFFTVFm3cKqb0wlt4PtwiQOr92secwTMNmh+ksYycU?= =?us-ascii?Q?EfaPd32I3zvetjtE7dq6QaAkuEDQ6rh85HXDfFeIbMA0OI5HKEXl5/aEH7HN?= =?us-ascii?Q?AbmulekjyvTIgY8OBdW8fiii8ert72ffs81dInaV9gEBTjvPA55DMONwrusr?= =?us-ascii?Q?S2hRXNbfO60WWlvhI6bQzKLfcrdztGviWe5PFkR4ttI3YDxUTD2lxoIHhvRx?= =?us-ascii?Q?rgueSewYez/RRCUnh/yUOjCE2XzLTiEOKqHR5O4f?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c216ce6-77cc-4aff-a953-08dc804b0484 X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB5744.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2024 01:51:26.7946 (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: cha4Z+VEYhUWVbqVvgWSTIR/7LbpbBQih3CsCXT3xNx+/3XdV2M4rx8hiB/zKzEo X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR12MB6476 X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1CA1340006 X-Stat-Signature: w8skqk7nzc7stext4ibfqw1494asbskd X-HE-Tag: 1717033890-60305 X-HE-Meta: U2FsdGVkX1/dbdj5bIYTqDwOpKhiVjTmYPxJTyIPvLjYreYbjxHtjAtpMPZ3VB4i/+28V7ZVtPZ6VxU9yeoX55iebQ5M1NhgxG91e7DbPXbzlf3RoXaJFcF+OwPzfadYeYnrqCcK8rGNQ/vwojZEzDhwq6XNpA5Pinv2c5ulJJvNbySJVIRzC1e72dBr/GCHhq+JOy5b2msD3B1D3w1DjvqGQQME4btL4Ssr+5u7BpZiUt80dGaKrFf8HyanjgtEaIyelNSm3MKYUSSIe1E08l7tmonVyR5SN1Llvl2SRmUTMI7rpVmweTfRGdN0fJLum8WM1iTp9i87HLZ4vJhZzqWbkxwjVWrZRCvHERjvibN8McJ0CGfewxJkDe5gdxJzvNE+GzNKP1hZ71Zzl0pv41fmHs3W3h6vmEkUxfNJja5fWkCsOMqWe7Qkc2Xd3it5om5H7gjvmUJan7ltAsHiZZLbTWIGAu2fdwIXMf6PGNiuf9CMh2rpO5+hSsDjwAahxSl+Io5QVO0ZVndRSDMJneqGZ+vLMSbaMz/GmlRZvRN4g4GVIYe8wOtqrwIJuHDd7J6q4IQ2fV/qCxCnt5qqSrDZs9HZ/fQf6KMR2lDY4Iafoc5uCwfJTq3x8OtC2XeAwMb52FXBtjuAx3S6F0mQG3IDqjFjD6oFSJsV8AZXpQlKWu40KRVHdp0YCJ3y5/PZy3sIn6NeBKO+VVa/PjaUTc899eH7JElEiGe+c0fF/nB2usiv0WzMtI8nxiQrHEajmksMpzu5Jhyy/Q0Pb9EEieZzSMLTj/xuX5vy+pmkbIuo6R50faC4FIh2P/8m5oyriPagX5wTC4R4HTPnMUgd2naO0fm/TsOivBR9ZjtbK4bJVajWrtJSO/8Vlxxl4QT+5cz33JLwESd2+iifq0/S0cLVPyL1HukmTUqWXjhBO4r+ygli7ahvDwpX7svricKhsU/FbZMCyeOhdn/unsK 1Y2R1oHb OD8s5TWNLv1ODTjDLj4RM5iIFUWGVoUeCtOM3S73q0UJHapViZhHPBHztDp3/aSh4QwKPtVJ74Oo0J6OhB1qKUN4WVIZt3OItMN80CmP73qUNLG4ebu947Ad6iWnpk20bpOHkNXZgZH2Wp0CYvr0/hWw8fcWUnNDYRtJ3z7M1pfxWDNJ2QhKq0ZPTlIgUeq6BBez0uVolQkpAtK6cBT29m68tGj36s/yk+p2nFz94YdLA+TwZ9nrlpex6n9XE1psBeXxjEWPelUyjlcPppqpNAynuVKHM42HtcIoq7j/S+JcEYNdxechAk9N4tw+Ti9GbAgOTSmfEeVFhB5+Z8E1sXfYtNgbSG92bOEVmjHuQut5Nirxreri58wrw0918Dm5avok7qsvvPJkXHtlD0ySXgCudfavQ75XXPyYXMKol7joDsXrzOtHNtJlogEjMhviTOR5brd/Tc11B+p8= 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: --=_MailMate_AB4EA8AF-C5EB-459A-BC64-00B2CF8AAC5E_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 29 May 2024, at 21:04, Johannes Weiner wrote: > On Wed, May 29, 2024 at 12:28:35PM -0400, Johannes Weiner wrote: >> Thanks for the config, I was able to reproduce it with. >> >> On Tue, May 28, 2024 at 12:48:05PM -0400, Johannes Weiner wrote: >>> Ah, but there DOES seem to be an issue with how we reserve >>> highatomics: reserving and unreserving happens one pageblock at a >>> time, but MAX_ORDER is usually bigger. If we rmqueue() an order-10 >>> request, reserve_highatomic_block() will only convert the first >>> order-9 block in it; the tail will remain the original type, which >>> will produce a buddy of mixed type blocks upon freeing. >>> >>> This doesn't fully explain the warning here. We'd expect to see it th= e >>> other way round - passing an assumed type of 3 (HIGHATOMIC) for the >>> remainder that is actually 1 (MOVABLE). But the pageblock-based >>> reservations look fishy. I'll cook up a patch to make this >>> range-based. It might just fix it in a way I'm not seeing just yet. >> >> tl;dr: With some debugging printks, I was able to see the >> issue. Should be a straight-forward fix. >> >> No order-10 allocations are necessary. Instead, smaller allocations >> grab blocks for the highatomic pool. Unreserving is lazy, so as those >> allocations get freed, they have a chance to merge together. Two >> adjacent highatomic blocks can merge (MAX_ORDER > pageblock_order). On= >> unreserve, we now have an order-10 highatomic buddy, but only clear >> the type on the first order-9 pageblock. A subsequent alloc + expand >> will warn about this type inconsistency. >> >> [ 411.188518] UNRESERVE: pfn=3D26000 order=3D10 >> [ 411.188739] ------------[ cut here ]------------ >> [ 411.188881] 26200: page type is 3, passed migratetype is 1 (nr=3D51= 2) >> [ 411.189097] WARNING: CPU: 1 PID: 10152 at mm/page_alloc.c:645 expan= d+0x1c8/0x1f0 >> >> I have a draft patch to make the highatomic reservations update all >> blocks inside the range, not just the first one. I'll send it out as >> soon as I have tested it properly. > > The below fixes the issue for me and survives a few hours of > xfstest/generic/176 for me. > > Christoph, can you please confirm it addresses what you saw? > > Vlastimil, Zi, Mel, can you please take a look? > > Thanks! > > --- > > From a0ba36bb9cd7404c07c7a56139fd52efc6981ced Mon Sep 17 00:00:00 2001 > From: Johannes Weiner > Date: Wed, 29 May 2024 18:18:12 -0400 > Subject: [PATCH] mm: page_alloc: fix highatomic typing in multi-block b= uddies > > Christoph reports a page allocator splat triggered by xfstests: > > generic/176 214s ... [ 1204.507931] run fstests generic/176 at 2024-05-= 27 12:52:30 > [] XFS (nvme0n1): Mounting V5 Filesystem cd936307-415f-48a3-b99d-a2d52a= e1f273 > [] XFS (nvme0n1): Ending clean mount > [] XFS (nvme1n1): Mounting V5 Filesystem ab3ee1a4-af62-4934-9a6a-6c2fde= 321850 > [] XFS (nvme1n1): Ending clean mount > [] XFS (nvme1n1): Unmounting Filesystem ab3ee1a4-af62-4934-9a6a-6c2fde3= 21850 > [] XFS (nvme1n1): Mounting V5 Filesystem 7099b02d-9c58-4d1d-be1d-2cc472= d12cd9 > [] XFS (nvme1n1): Ending clean mount > [] ------------[ cut here ]------------ > [] page type is 3, passed migratetype is 1 (nr=3D512) > [] WARNING: CPU: 0 PID: 509870 at mm/page_alloc.c:645 expand+0x1c5/0x1f= 0 > [] Modules linked in: i2c_i801 crc32_pclmul i2c_smbus [last unloaded: s= csi_debug] > [] CPU: 0 PID: 509870 Comm: xfs_io Not tainted 6.10.0-rc1+ #2437 > [] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debi= an-1.16.3-2 04/01/2014 > [] RIP: 0010:expand+0x1c5/0x1f0 > [] Code: 05 16 70 bf 02 01 e8 ca fc ff ff 8b 54 24 34 44 89 e1 48 c7 c7= 80 a2 28 83 48 89 c6 b8 01 00 3 > [] RSP: 0018:ffffc90003b2b968 EFLAGS: 00010082 > [] RAX: 0000000000000000 RBX: ffffffff83fa9480 RCX: 0000000000000000 > [] RDX: 0000000000000005 RSI: 0000000000000027 RDI: 00000000ffffffff > [] RBP: 00000000001f2600 R08: 00000000fffeffff R09: 0000000000000001 > [] R10: 0000000000000000 R11: ffffffff83676200 R12: 0000000000000009 > [] R13: 0000000000000200 R14: 0000000000000001 R15: ffffea0007c98000 > [] FS: 00007f72ca3d5780(0000) GS:ffff8881f9c00000(0000) knlGS:00000000= 00000000 > [] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [] CR2: 00007f72ca1fff38 CR3: 00000001aa0c6002 CR4: 0000000000770ef0 > [] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 > [] PKRU: 55555554 > [] Call Trace: > [] > [] ? __warn+0x7b/0x120 > [] ? expand+0x1c5/0x1f0 > [] ? report_bug+0x191/0x1c0 > [] ? handle_bug+0x3c/0x80 > [] ? exc_invalid_op+0x17/0x70 > [] ? asm_exc_invalid_op+0x1a/0x20 > [] ? expand+0x1c5/0x1f0 > [] ? expand+0x1c5/0x1f0 > [] __rmqueue_pcplist+0x3a9/0x730 > [] get_page_from_freelist+0x7a0/0xf00 > [] __alloc_pages_noprof+0x153/0x2e0 > [] __folio_alloc_noprof+0x10/0xa0 > [] __filemap_get_folio+0x16b/0x370 > [] iomap_write_begin+0x496/0x680 > > While trying to service a movable allocation (page type 1), the page > allocator runs into a two-pageblock buddy on the movable freelist > whose second block is typed as highatomic (page type 3). > > This inconsistency is caused by the highatomic reservation system > operating on single pageblocks, while MAX_ORDER can be bigger than > that - in this configuration, pageblock_order is 9 while > MAX_PAGE_ORDER is 10. The test case is observed to make several > adjacent order-3 requests with __GFP_DIRECT_RECLAIM cleared, which > marks the surrounding block as highatomic. Upon freeing, the blocks > merge into an order-10 buddy. When the highatomic pool is drained > later on, this order-10 buddy gets moved back to the movable list, but > only the first pageblock is marked movable again. A subsequent > expand() of this buddy warns about the tail being of a different type. > > A similar warning could trigger on an order-10 request that only marks > the first pageblock as highatomic and leaves the second one movable. > > This is a long-standing bug that's surfaced by the recent block type > warnings added to the allocator. The consequences seem mostly benign, > it just results in odd behavior: the highatomic tail blocks are not > properly drained, instead they end up on the movable list first, then > go back to the highatomic list after an alloc-free cycle. > > To fix this, make the highatomic reservation code aware that > allocations/buddies can be larger than a pageblock. > > While it's an old quirk, the recently added type consistency warnings > seem to be the most prominent consequence of it. Set the Fixes: tag > accordingly to highlight this backporting dependency. > > Fixes: e0932b6c1f94 ("mm: page_alloc: consolidate free page accounting"= ) > Reported-by: Christoph Hellwig > Signed-off-by: Johannes Weiner > --- > mm/page_alloc.c | 48 +++++++++++++++++++++++++++++++++--------------- > 1 file changed, 33 insertions(+), 15 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 2e22ce5675ca..754ca5821266 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1955,10 +1955,12 @@ int find_suitable_fallback(struct free_area *ar= ea, unsigned int order, > } > > /* > - * Reserve a pageblock for exclusive use of high-order atomic allocati= ons if > - * there are no empty page blocks that contain a page with a suitable = order > + * Reserve the pageblock(s) surrounding an allocation request for > + * exclusive use of high-order atomic allocations if there are no > + * empty page blocks that contain a page with a suitable order > */ > -static void reserve_highatomic_pageblock(struct page *page, struct zon= e *zone) > +static void reserve_highatomic_pageblock(struct page *page, int order,= > + struct zone *zone) > { > int mt; > unsigned long max_managed, flags; > @@ -1984,10 +1986,17 @@ static void reserve_highatomic_pageblock(struct= page *page, struct zone *zone) > /* Yoink! */ > mt =3D get_pageblock_migratetype(page); > /* Only reserve normal pageblocks (i.e., they can merge with others) = */ > - if (migratetype_is_mergeable(mt)) > - if (move_freepages_block(zone, page, mt, > - MIGRATE_HIGHATOMIC) !=3D -1) > - zone->nr_reserved_highatomic +=3D pageblock_nr_pages; > + if (!migratetype_is_mergeable(mt)) > + goto out_unlock; > + > + if (order < pageblock_order) { > + if (move_freepages_block(zone, page, mt, MIGRATE_HIGHATOMIC) =3D=3D = -1) > + goto out_unlock; > + zone->nr_reserved_highatomic +=3D pageblock_nr_pages; > + } else { > + change_pageblock_range(page, order, MIGRATE_HIGHATOMIC); Don't you also need to move (page, order) to MIGRATE_HIGHATOMIC free list= here? > + zone->nr_reserved_highatomic +=3D 1 << order; > + } You could do: zone->nr_reserved_highatomic +=3D max_t(unsigned long, pageblock_nr_pages= , 1 << order); instead. But I have no strong opinion on it. > > out_unlock: > spin_unlock_irqrestore(&zone->lock, flags); > @@ -1999,7 +2008,7 @@ static void reserve_highatomic_pageblock(struct p= age *page, struct zone *zone) > * intense memory pressure but failed atomic allocations should be eas= ier > * to recover from than an OOM. > * > - * If @force is true, try to unreserve a pageblock even though highato= mic > + * If @force is true, try to unreserve pageblocks even though highatom= ic > * pageblock is exhausted. > */ > static bool unreserve_highatomic_pageblock(const struct alloc_context = *ac, > @@ -2041,6 +2050,7 @@ static bool unreserve_highatomic_pageblock(const = struct alloc_context *ac, > * adjust the count once. > */ > if (is_migrate_highatomic(mt)) { > + unsigned long size; > /* > * It should never happen but changes to > * locking could inadvertently allow a per-cpu > @@ -2048,9 +2058,9 @@ static bool unreserve_highatomic_pageblock(const = struct alloc_context *ac, > * while unreserving so be safe and watch for > * underflows. > */ > - zone->nr_reserved_highatomic -=3D min( > - pageblock_nr_pages, > - zone->nr_reserved_highatomic); > + size =3D max(pageblock_nr_pages, 1UL << order); > + size =3D min(size, zone->nr_reserved_highatomic); > + zone->nr_reserved_highatomic -=3D size; > } > > /* > @@ -2062,11 +2072,19 @@ static bool unreserve_highatomic_pageblock(cons= t struct alloc_context *ac, > * of pageblocks that cannot be completely freed > * may increase. > */ > - ret =3D move_freepages_block(zone, page, mt, > - ac->migratetype); > + if (order < pageblock_order) > + ret =3D move_freepages_block(zone, page, mt, > + ac->migratetype); > + else { > + move_to_free_list(page, zone, order, mt, > + ac->migratetype); > + change_pageblock_range(page, order, > + ac->migratetype); > + ret =3D 1; > + } > /* > - * Reserving this block already succeeded, so this should > - * not fail on zone boundaries. > + * Reserving the block(s) already succeeded, > + * so this should not fail on zone boundaries. > */ > WARN_ON_ONCE(ret =3D=3D -1); > if (ret > 0) { > -- = > 2.45.1 This part looks good to me. -- Best Regards, Yan, Zi --=_MailMate_AB4EA8AF-C5EB-459A-BC64-00B2CF8AAC5E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEE6rR4j8RuQ2XmaZol4n+egRQHKFQFAmZX25wPHHppeUBudmlk aWEuY29tAAoJEOJ/noEUByhUoD0QAJdeJGTXXxq+uP7rK58hgTPStDzGcBl0txW1 2jxuLGygKOvEvctx9tnJXsMu533+7ym48kogjydLSfc80lorOMywwWaVfgxtzubW 4K/TCoxzW4ui57LMczu9HOy2Z7gbX4qOSBYVANNAaXdi+Cdz3w2i9Pdb0/W2gkxJ +AOif93brENO/k/ypDt+QKw3PN9uFrWsBlUNi9kf9HonQsK0e7G2ANLZ6glyE2NP zWP9egJj1TDpzd1YNd+CgffAqILTe/6ELzbvZhUqHzFxohpADTG0TGA9Nx30mM2Z CSyDlWBCsoSaqCM7obmuJmGIJBwxcFdOZiIHQwG88WX7Fqr3VHoPvc/ubAJGLeWd S291WrX6Atv+zTUIo3olUvfqrSyC/qt+34J9Pl+V3AvZl6sCVlrGqLuTBBaDQPvV gY0BiWGMU9JDIfXrC9dVSILNOFvBioyPJVlAF6zB9B2LQdHMqAzr3B6Vv7Xf1mck TyLpQjORxetHmQECEcBPG5tnMe2sdbnhpaZ4y9Qvo7Z9g0fkSyqa7DXCviXr3hbh 8Y6/4PA5KeE3Tj6LZUke0e4bHCpJ+DQKML+uC3pPt1f1DwAPNTe8TjYP7TqCZgNg UraaAgulEL5DGWoql2ZkRlbPjelhdWsWMqS7Z/VTwAESpfZiwpQrzVeXOqNnFQ7+ UULglOlq =NO+h -----END PGP SIGNATURE----- --=_MailMate_AB4EA8AF-C5EB-459A-BC64-00B2CF8AAC5E_=--