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 71BA8E77188 for ; Thu, 2 Jan 2025 15:54:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D61856B00D0; Thu, 2 Jan 2025 10:54:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE96D6B00D2; Thu, 2 Jan 2025 10:54:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3B7C6B00D3; Thu, 2 Jan 2025 10:54:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8D2ED6B00D0 for ; Thu, 2 Jan 2025 10:54:15 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4C522B07CF for ; Thu, 2 Jan 2025 15:54:15 +0000 (UTC) X-FDA: 82962956118.19.BD45907 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf29.hostedemail.com (Postfix) with ESMTP id 5CBA3120006 for ; Thu, 2 Jan 2025 15:53:00 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=nktGCLe8; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=MafcQb3y; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf29.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; 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=1735833218; 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=VldzegU2u4FlfT/AcWl4PCsq9rN+58Z+gfTZwmYu3L0=; b=dAq0UlvTIRa7RIsCp44uSKB2apPhTFsFCSF0s+Ex9qRGQYMwdH+Q7XEpgBGYSy1OyklVub u0guj8BjkfoNthoXY0LcF/S5YISmI0VFy7TP+ZVTIWMLhrTJp2RvIDontX35pt5BwipHoQ xWDq1gRGRCjagc1jFOAKwJJ/5l1CrsM= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1735833218; a=rsa-sha256; cv=pass; b=sb/z8GWqptmRH91VSzSSFoUFqPgQ1kI784L39qkoIgc8nIL3ItDBr+Y0jfXGyT9aCZAi+1 AyttQwfdItptTLKDS4gaVWcU/UkrhFGvhXsJFuS0VCpPLCqBBmA7bh+7y5TzH7WQ+ljdjS 6Y5X9BiEZPaEY+yYqSEKpnXXlJ9KMZs= ARC-Authentication-Results: i=2; imf29.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=nktGCLe8; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=MafcQb3y; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf29.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 502Dtwfu014852; Thu, 2 Jan 2025 15:54:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=corp-2023-11-20; bh=VldzegU2u4FlfT/AcW l4PCsq9rN+58Z+gfTZwmYu3L0=; b=nktGCLe8T13AOTro4l60hkBRaRKDYm83QM bhdVjfZiI52ulRhYl3DvjytmFao+VweLzgdpKeNcK2vt6f8sDf7uvD2YeALoyDOG yq1Sw5Fnpr6aeTE0r/tvnvtsjQPvEor5mgmL8EbFqaUTbfWeZFra2Zd37X+hNGGg tBPuqhfMTnYrgMtRaobgdhatyK4XhFKyJsjaaLtGF+hbY9cD4ZO+1m6brP1EHKFo Bdsm75KMTX6QoMHiWKWnGGCKxVjyo74gjMOn4DBjIQnxWF1RnucGuW3DcyGtZ7gE B/f8pqV/PFhB1LTKcQVAhknlQkrkVF8V7i9+7+qlEUVZpnk//VsA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43t9vt5hwg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Jan 2025 15:54:01 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 502EiunU011775; Thu, 2 Jan 2025 15:53:59 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2173.outbound.protection.outlook.com [104.47.57.173]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43t7s8qxd9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Jan 2025 15:53:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tNihdu/Otr8Us+4I9a4b7Fnf+kwqF/Jfy4LtXsIiDqdAg61H19i++06zKHJ6kqCiRWwKY2ZX57bRlwe945jcI1BvdDqN38n3NcJBMT6Dy85ZfdfU/KAFKhCDw4yyHVWSyaHPLjlAOzZuoKr2xCwoyHl+00zKM+3Z0G8WXvcnMny9l3K5q9tPfJwj1/2qttYG84HmF3EZ+7ofCYYQvGksvOj3CT9KGCwpgOSU9MkNaaoSFqE8mLihzjx40twkebpXw6m2D4ESsr+lPEXYll6r9zgoQ7AydspAziA/eXiGPq7wJ8A0Wgh8hA67M79kBHOlDa3IgGwjdCO0rqaxssDTkA== 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=VldzegU2u4FlfT/AcWl4PCsq9rN+58Z+gfTZwmYu3L0=; b=N+9DsmCPzCEy8+d5UHotqajvzjJBdWJKuPGXSYdujs3mGlysI0Ut+HyH/UAKsTJ8oa/QBc3FqJu7U8IH/1JDse+QWNeuarPY7qpCw40ve8j+0J4jyBiBrQdlzxgIb6x2atz1I2hb1CXuprzmrKcdMFCPwGP+2JheFd0R4L47OiUGESZu7lzxe+n765lQPPYvAx+Csy/u4nu9aE4z7uOoVTfs3E26Z+0GPCpTtflRiymjoCzPken0pLG1JkYLB8I3IW36GWxHQfGN4OCM8DSsF/Hnm1PoBCl7YXglo6vYHfiWKSlcPPktdS8GSi/8ByqVhCqT6nDl9qSmDPBtI28OkQ== 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=VldzegU2u4FlfT/AcWl4PCsq9rN+58Z+gfTZwmYu3L0=; b=MafcQb3yIPSGCNPutz0I6Ur/Qs58NYoLeN/zEgGw4TcnseEEt3aLj8/rpLEOVCZ6zTWyO9Do15wyGZLOQdDgGhGrFqvgHu+eA8jdyWZdyYcrgDO8aE540tJITC5v055Xm+Kmh9dtKFZhiZd/XMUZrEP6UValurGaufGCtfXWaEI= Received: from BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) by SJ2PR10MB7597.namprd10.prod.outlook.com (2603:10b6:a03:53d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.12; Thu, 2 Jan 2025 15:53:52 +0000 Received: from BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9]) by BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9%4]) with mapi id 15.20.8314.012; Thu, 2 Jan 2025 15:53:52 +0000 Date: Thu, 2 Jan 2025 15:53:42 +0000 From: Lorenzo Stoakes To: Rik van Riel , Shakeel Butt Cc: David Hildenbrand , Andrew Morton , Chris Li , Ryan Roberts , "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, "Liam R. Howlett" , Vlastimil Babka , Jann Horn Subject: Re: [PATCH] mm: remove unnecessary calls to lru_add_drain Message-ID: <71f8f499-1c65-4d70-8358-ccde4d69fbbc@lucifer.local> References: <20241219153253.3da9e8aa@fangorn> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: LO2P265CA0263.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::35) To BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB3366:EE_|SJ2PR10MB7597:EE_ X-MS-Office365-Filtering-Correlation-Id: fd28889e-a43b-4aa2-d0cb-08dd2b45a79f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7416014; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?2iCRDv4X9elJfkfdum62MdU3DVRVXuUWpVCoznpsZQvMi4PxXLVh8RT0pUtG?= =?us-ascii?Q?wCq/6/3A7p487T948v+e0UF3LG7XGhyl24V5N2RQQUs5sFa/f5u/w6XCWUgt?= =?us-ascii?Q?jgqRvOdV/FQQRoR/1YmCfz8UhS8tTmnH80B8GwOuEELgH5JTKcI7JhTt317E?= =?us-ascii?Q?hryi/xdG8Lhwn9jDDZfu3y34knTPd4E/AQjpZ2HVhPYG8Q6ZjMw+MLWWNzHE?= =?us-ascii?Q?Y0XvbTjzNYY/XlexGQd5ySWaQRq56JmTmLYDe/o+dTLjeUxMOXzij4rOIZOe?= =?us-ascii?Q?v84yKb622x272LlVLr2+W4+7TDNIgXJVTWlnTG8p/TafnEq/B1c14OFLHo7c?= =?us-ascii?Q?+lyVKhd1s7aCNitZFxL/Pp+8mev5NP5vO3pFFuakj4VlLzTGIuYGfgN0uSWz?= =?us-ascii?Q?6xaCZ6kReUJKzBoHDj4px0hzqEIqzBU+cr9ltSGpqt+3JWfx+KJZKdfAi4rK?= =?us-ascii?Q?OCODoWKVmafk/R+RiNRvWY1qIAgMPt2RKFy1eIaWPKVNjCcbtpYZpcXtkAQt?= =?us-ascii?Q?O2U99x00urh/Go7uqhAOZWRkoyUXkDw398K+qGIrRvmx5phdVqsKMYrn1oQk?= =?us-ascii?Q?5GB+9cTlZYLzXh5AHlUctEnRC8CQZn36QHAmMq/RmOKAfudxqYU5ZWDkzXVx?= =?us-ascii?Q?Jr76c6kit5i/pM0T6K9QI/F6dYsoPUbvtmVH2AWoaqjFo7iKLAx+xiSTy1UZ?= =?us-ascii?Q?fElfwPt/KTaJb5dMMoIxKs9XjVCXpF6fq0nGGyq8ZxQ3g5oTIkd6AREpHFOo?= =?us-ascii?Q?AxmzdyrlqRsqJuOqMZiwmP24LtdsQFqSaJFtGEUhUY6St/E+c1ocaKQCd3LK?= =?us-ascii?Q?IJ5vLMNWBv/ur34FUMpLiihtY7Kg0prWi82Z4eFtJJSdFPF929eJqEaCnZPz?= =?us-ascii?Q?cT824fMpU8Id9cAJb81FoSMphAd3Pwu2EJ9zidMdwiinw5TYsos/C6AJ3top?= =?us-ascii?Q?jZSoEpk3INKN1g7X+tQplWgceF7v5Q6yWpK0GBRVVgbqGgLeWvRpex+xIHU/?= =?us-ascii?Q?GKOxgu4aIDssodYTsTirGSHaUuyIoJaoDECzYuDtD7schS18MlsIokUzrmlZ?= =?us-ascii?Q?as+xc4lBFQNrEje19LyL5PqrSrC8UXNsFq7qT5xVojzzjCCpPDZ74t4+d43b?= =?us-ascii?Q?nsYKJTp+k41Mnev/XVaip0Q1vjzfZga5FBgTvAVT1ir4FM+2in0gey4O3y5N?= =?us-ascii?Q?yaRUUPBCtsRVYgyUEWtcsVpZYjVW+3FHgTTca0ZXUc97r6QyMjixLmbcYeHB?= =?us-ascii?Q?YHel2NXcZVGAd4mvVyGC0zw3a7GEUxz7+BbMgCNOqpq4f2+MsQZP2rxd40lE?= =?us-ascii?Q?NqFhaosJBXsYzW8TF+lCG1n4gNnLcL63LbfD7x0gCnhnPxYatiQJfOpfYGt5?= =?us-ascii?Q?JFvkf2ABELuVUWI+MItUVIYZZZo+EO3KxgXMNn1fkAOwYF8xlA=3D=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR10MB3366.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7416014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GCC+sczXAddguAZi2Lenrs0dpQEC7KUtu0aKmAy1pvAMgYILmH9gfSuJzldP?= =?us-ascii?Q?QaYmHvPWaulPMFEOG8kW1PSkee9UcmAVdBfLUjNF0Hbe3Fho//b85e9rh65Z?= =?us-ascii?Q?qETEI17ytNE1C8iMRf0CwQS+UeK69ANdlGTAqE3pMNdvFW52sbJ+dzxpuObp?= =?us-ascii?Q?p841JwMpqk0M8SsxhcOHGgoaWk3jddMFwcat22a5+TAmUR9SiLkj5E2gA3w9?= =?us-ascii?Q?48os6Pc9cgN0LIyOj3ugqNXnApy8BApDOGXzURacC7YMntbHT8wZbjk9NOHJ?= =?us-ascii?Q?KRX73Doxn5ewMtgnYRunrj/ZwniyKj6GaFyywkZ7AmYRMsBVXeUrM/ZXVPWE?= =?us-ascii?Q?yDGn/Z/15Dgcub6WIJ7/vi9mDgC9/RRKuQvmYSJ3u+yaEK9kFdgYJGG8Kedc?= =?us-ascii?Q?KIgoPSp3LrIqkCcR7Kemb9EKnSVCtczpsDzkLeo1U4aB+Vcu9qIclogp94SC?= =?us-ascii?Q?wDxuKUFoaI9QIdRfj2hatfbzacHinbOQdVQ1W2Eh/8jKTDlf7N51Yhr67T4p?= =?us-ascii?Q?m7f0O+ggAAx/HAKO79BYFAMqOm+Zjs4YZfCrilbEebWtXfCsx8+dOow8de3y?= =?us-ascii?Q?O5Pn5qpuzD+jf9UiQOOEegTE6BTvwfRYMr2YXszQNHBjd2FZYuX/lXHroWy9?= =?us-ascii?Q?qNjvB5121WNsAwTtUmSFl9uP/4MUuFLQbxv6lxRCaYUHK/Feezr5jM2xUtxn?= =?us-ascii?Q?iIfaSQQhd2ln4G+tw33e1sReIdEX54R+TpOtPvYnrI/zkElxMBSrCqSuTurD?= =?us-ascii?Q?ns+FWO8uv96HDHeoqIMACEd2KgAx5yR2vGwlPpWffy3g79+8CATVNQf+Qz+t?= =?us-ascii?Q?m1l/BzZrb1zhjPxesdyKpOEgjapst0Fw3SDciBs1zCR/Xxw0kYjArYoJrSSS?= =?us-ascii?Q?641CMzzwjlOdISf6mdqhjRwOlBZuseggsPyWSQ+xfLvFggoQZoqh70ytb+28?= =?us-ascii?Q?MvyQ2rWEm5Y5Fr5pBL0W4BGWZkcIqxj1dQso+Aldrlem/Rvijb6GutDqUPXP?= =?us-ascii?Q?NMK+uqnOjriTXa9Mt6yhn+jENsrZ4CLTnq2d5hoI7JrgvfUT8iOSuIfMey7H?= =?us-ascii?Q?fiDaJU6/M+PAllXZ8TbKcMT1L+vhILp0xJd8hYnojBugRCHf8e2v3eynXd9a?= =?us-ascii?Q?zpmh8TgVcNHswEICHrFTj5SDsrdCujhwt+Op/XnRIppTqGxBnDpnyGgg3/rU?= =?us-ascii?Q?TtwODS39mvZhtAI5h3EIO5/8e+Oaqss2jo7KBH7G7lDGf5lJu+bfZYCs9X9e?= =?us-ascii?Q?YCEOCwfdInXfx4cYp6hP1oAcGGAaGjoFWeW/LNEA2oAPpiAIBVAjYKrGhYlz?= =?us-ascii?Q?P59NGRFFAco17go/ECtm41dZ1ze7GUQToNothrvwCZ/0YNeuOpemVdJWG9o0?= =?us-ascii?Q?3EqaqMSQLX0Ku1tY+nPWvZ49voTcV1gXjQxeq6xOFUcfJdkct6+5QnASVgb9?= =?us-ascii?Q?bxzfMiR7ysht6bRgZ6wFsAVZIvCsKle658PRWISLoptJo4STx4c40kUJpyxd?= =?us-ascii?Q?2kdWBMNeYz3OMn99jeT+vV2bUr+HPQzl8NTd/pJXnDyFj+ZdTx6mBGexZ3Z6?= =?us-ascii?Q?hC7O34cZu9XDvzzvMx1hJvuQrKIhrixUwV/qFt4yCfuKjAk50CM2AI0AoMDG?= =?us-ascii?Q?5w=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: MVG2visS39TcHGMo4xi7xJeRaB7eEnf+oBtT08JOX3Z1HP0teGkH20yHPhTRb+JxuPWIzTd1PO2HemsyztLuFTa7JgOy39PBA4aooMy9YrVO8kWPw2qfSh49ekvXUvXf1oNV8Tt/ygSrwcF0+Po7kzwxEX9vN9vmjJlmIwT2Y+ehJXOryj1ofUpyvT72s6YcAiN7q0EWTDKdrRpfvV/+xIIr8ZWt1s1NPPRhLjU0vPdCJ5HXfB3ucs1RBEaGn9XfE9NknmxjM1JcQWxvNgVxFSmk0+JIhEjnhx/GbuggvBUG9osikUL6mIe2p9liaTQG2GzVj4aWMSfkQpD4r4QbkEEPNMmvCCFMroQEQ3DfVjV8ay/ZbPHXBes/SJTwkycyJwlDFRdDnzKbfoyXG7qEfA4avwiNauDMxQenP09Drt5c/Qp6WvmDcLhbvcmCLA2qb0jbJNBqPxJy5TdDM/Tjl5xoTifsJLjiJMcsuxWlMqDXmnNxvMFUkDPL/DdU+naCH2KEk2mJ2xsFz4A8koiTNL30Tzhobj6DUhs5BcD4Iv+T3YmmTJZmmy0uCFuKLXUT825QKqWOtO4CWqE/88wb1tlPe94Z9YqkXNbgOM0yFuM= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: fd28889e-a43b-4aa2-d0cb-08dd2b45a79f X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3366.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2025 15:53:52.7282 (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: CUF23tD3BrHmO6SYQro5TEXsW1ZJ6P+WyYsf1d9bjakKJNcz8PahWsjiRxwCpIw+mturMcnCLLEtNhTDvCdSLImyKsT5LBVdavBfx0400RU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR10MB7597 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-02_03,2025-01-02_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501020139 X-Proofpoint-GUID: 374EVUlDKG33RVyUne-o2jLB9sqkgoih X-Proofpoint-ORIG-GUID: 374EVUlDKG33RVyUne-o2jLB9sqkgoih X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5CBA3120006 X-Stat-Signature: 8wb79s1xwnqi7ez9uwy4qwutckw8bppo X-Rspam-User: X-HE-Tag: 1735833180-528771 X-HE-Meta: U2FsdGVkX1/iKwJhvnyPnTe/5gPRB2XY4On7KmjzTiFOQ4dDN/NZ8TVjpc8CnwdDTPTSBq/y6cujia/ESuV5ahxSEFUjeYJYrcSQTtwL5uJSHv7M+6/FAyQDK56v6JnZQPHa6VZO3z8T27Zb7Dp1RJ0NNGLXD7OelVMAtHuvw2ap6oxi9urSK9E8el/pY5+5TGHLyt/Nh1ZkIpzOJl5oS2D/5js3jrKjonVUO9fTcGqOeduhqTISziqBAX7856Tifog4s7CAl1HZ3RbvY5fwwS4RVOYWtFyVEwMf9GjWP7UCc5n/4g/qp3UxL18NdvMoDwZnkezZLwrZ4fFsC44ni7ggFc5P6k9HHPP9w97XchKA/eKsb9hop0iq3bI9MvC+Jen/IjY9HL5sTyB452gmOOrTtvAZW0XDegdV/5Zjzybig3ejTYNyXcNRME7n4ES4NFnvY4QAy5oJqp8fogx4njRklPmvLWQOJ9GDeZmFA7303nAoCwYsNdyRS8NbBfP8bAATQ+Q0l33nuD63bjY7HlguFF8W0t/SMydVJ0JbhfhCTAEDp8Vj5SE+RcZYanwEi13KXgwYx5Fh1sWSLRLuXeLsGg5pTAn9TTTEy4/srJ6PBGsoPoReyJeIb8FJzB5pdg26SJIJxrTkONd1SXR5++In1mWMxMp5kY18cnbVJlWdx0lUlNICL2Y4o18NSfRplUaZH1i6A0kTs4QM5XR5cFOs6OgKNu9mBK88QnAdYR0WtgVEWZHWy2fdH94DIVqNUyCMuPxW0Ih52bPRIjzeB1kKiQwwb7zbnnULH+LC69ykbG8lZTgAgxZHRiVOOJqrw8w0Cod8buszTYU9EIU5Tok0AW05VBD10aQKI++sPe5yveXdHxUtYyA8dYoKNvunsHFAZtCL6+a5XIDII13Lzfxfm7HdvGAmmLxW7xm0v44aIpWOAjrGa6S0PiJuMiT/WNu3PLzihPIki3tgybz 0knZwaxd WxbIZcRBnUl/wjWGJAK3BCSI8UxlS/iZXWIOTEX3dhmOJDA1nvP6Z0EX50HwoLyiZvpD/dt/+CW7X6aQxv0vIQ/hi2ijkVDQ2nhmti22V9CqwB3qjDzjdE5gXQBQaQUqwUI52cXRUGkKsjgbnv+02k1ugjsYhqlKFGfLgLPlfyb6kQMVQmJRWE33hEN7HSCX3+T8mFViClBqI4W3DP5S5sMlRKvpULQ8GFo0qgWRNp8lQLNWy4406KWbPIUP5s0rxFlKd/KpshL6T9MSDzl0zzDQthB2uNouwh6udcxvnPaApTOLfvEALhb5Jj7HTJ66XYXEpOtZXRnuZkjTFJ58f+OabgzfRll3I4TWmG2V4K/enSpLW+8SQiN9PijW+YDmgMAd5XKRG3PDvYiOgURptYJepkRa9RY9Iaqp/n15UWu65nZI7Yd1XvwUrBAO1YwMprl1781ajBZXkMXB/UY3WzdQ3EmcdBt06QCfOiqsBF94uk+XhRp9Nb3/zHIdSPRRyGKZKft0boQw7lluYKKoJY5CbfvuoEE/8vNU9Vata+8u0/qHaMTw8Jf5fRFu78yik98pfx9dvmqcHl0yLdgppu4V/tYP96xvwSiSIjPga7nYFMTj8/8UTpQorOm9+InHppqy9mcyA+XhQ/o9yxZzYwyffST2g+7VsFSTkfrnASVozqxXni2G741rYppSsero00hO5MU4/oRWx7cR9uz0bcRMs98yODOVt0Ecj 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: +mmap maintainers/reviewers On Fri, Dec 20, 2024 at 05:10:31PM -0800, Shakeel Butt wrote: > I am trying to go beyond the first git commit to find the actual > motivation for adding these lru_add_drain. > > On Thu, Dec 19, 2024 at 03:32:53PM -0500, Rik van Riel wrote: > > There seem to be several categories of calls to lru_add_drain > > and lru_add_drain_all. > > > > The first are code paths that recently allocated, swapped in, > > or otherwise processed a batch of pages, and want them all on > > the LRU. These drain pages that were recently allocated, > > probably on the local CPU. > > I wonder whether it might be worth adding wrappers that explicitly self-document this? Naming is hard obviously... and any I think of seem silly ('lru_drain_recently_allocated()' sucks) but perhaps it might even be possible to set flags to say don't put allocations in folio batches to begin with? Like local_unbatch_folios(); ... ... local_batch_folios(); Or even a GFP_ flag? I mean maybe it's forbidden to suggest new GFP_ flags at this stage but still :P Though perhaps this could go terribly wrong because of preemption. We could at least perhaps comment lru_add_drain() to provide this reasoning? > > A second category are code paths that are actively trying to > > reclaim, migrate, or offline memory. These often use lru_add_drain_all, > > to drain the caches on all CPUs. Similarly I guess it would be nice to have something semantic hinting at this. Again, I'm not necessarily going to suggest something sensible, and perhaps it's pretty implicit by 'drain all' (and context). But again it might be nice to add a comment providing reasoning as to why we might want to do this. On the other hand, I was already pretty clearly aware from the context of this invocations as to why (we are reclaiming/memory offlining/etc. and having stuff in folio batches is not useful). > > > > However, there also seem to be some other callers where we > > aren't really doing either. They are calling lru_add_drain(), > > despite operating on pages that may have been allocated > > long ago, and quite possibly on different CPUs. > > > > Those calls are not likely to be effective at anything but > > creating lock contention on the LRU locks. Really nice to try to attack this as LRU lock contention, I gather, is one of the more significant sources contention observed in practice. > > > > Remove the lru_add_drain calls in the latter category. Are these all the culprits, are are there more lurking out there? > > > > Signed-off-by: Rik van Riel > > Suggested-by: David Hildenbrand Thanks very much for chasing these down Shakeel, the lru drain logic is not my area of expertise (currently :) but your reasoning seems justified and David and (obviously) Rik's support of this gives me confidence, so: Acked-by: Lorenzo Stoakes > > --- > > mm/memory.c | 1 - > > mm/mmap.c | 2 -- > > mm/swap_state.c | 1 - > > mm/vma.c | 2 -- > > 4 files changed, 6 deletions(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index 75c2dfd04f72..95ce298dc254 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -1935,7 +1935,6 @@ void zap_page_range_single(struct vm_area_struct *vma, unsigned long address, > > struct mmu_notifier_range range; > > struct mmu_gather tlb; > > > > - lru_add_drain(); > > The above was added in [1]. It seems like the motivation was that the > lru_add_cache was holding to some freed pages for long period of time > and some workload (AIM9) was suffering to go to reclaim to flush those > pages and use them. By draining here, such a workload was going to > reclaim less often. (I kind of extrapolate the reasoning). > > I think now it is ok to remove this draining as ratio of pages getting > stuck in such a cache to the total RAM is drastically reduced and these > pages becoming the main cause of slowdown is almost zero. > > [1] https://github.com/mpe/linux-fullhistory/commit/15317018be190db05f7420f27afd3d053aad48b5 > > > mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma->vm_mm, > > address, end); > > hugetlb_zap_begin(vma, &range.start, &range.end); > > diff --git a/mm/mmap.c b/mm/mmap.c > > index d32b7e701058..ef57488f1020 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1660,7 +1660,6 @@ void exit_mmap(struct mm_struct *mm) > > goto destroy; > > } > > > > - lru_add_drain(); > > The above was added in [2]. I think it was just a move from the callee > to multiple callers i.e. from unmap_page_range() to unmap_region() and > exit_mmap(). For unmap_page_range(), lru_add_drain() was added in [1]. > So, I think the same reason can apply to it i.e. we can remove it now. > > [2] https://github.com/mpe/linux-fullhistory/commit/5b0aee25a3c09b7c4fbb52a737fc9f8ec6761079 > > > flush_cache_mm(mm); > > tlb_gather_mmu_fullmm(&tlb, mm); > > /* update_hiwater_rss(mm) here? but nobody should be looking */ > > @@ -2103,7 +2102,6 @@ int relocate_vma_down(struct vm_area_struct *vma, unsigned long shift) > > vma, new_start, length, false, true)) > > return -ENOMEM; > > > > - lru_add_drain(); > > The above was added by commit b6a2fea39318e ("mm: variable length > argument support"). From what I see, there was no reason provided and I > couldn't find on lkml any discussion on this. I think it was just > following a pattern from somewhere else of lru_add_drain() along with > tlb_gather_mmu(). > > I think we can remove this one as well. > > > tlb_gather_mmu(&tlb, mm); > > next = vma_next(&vmi); > > if (new_end > old_start) { > > diff --git a/mm/swap_state.c b/mm/swap_state.c > > index e0c0321b8ff7..ca42b2be64d9 100644 > > --- a/mm/swap_state.c > > +++ b/mm/swap_state.c > > @@ -317,7 +317,6 @@ void free_pages_and_swap_cache(struct encoded_page **pages, int nr) > > struct folio_batch folios; > > unsigned int refs[PAGEVEC_SIZE]; > > > > - lru_add_drain(); > > This was added in [1] as well and I think the same reason applies. > > > folio_batch_init(&folios); > > for (int i = 0; i < nr; i++) { > > struct folio *folio = page_folio(encoded_page_ptr(pages[i])); > > diff --git a/mm/vma.c b/mm/vma.c > > index 8e31b7e25aeb..d84e5ef6d15b 100644 > > --- a/mm/vma.c > > +++ b/mm/vma.c > > @@ -398,7 +398,6 @@ void unmap_region(struct ma_state *mas, struct vm_area_struct *vma, > > struct mm_struct *mm = vma->vm_mm; > > struct mmu_gather tlb; > > > > - lru_add_drain(); > > Same reason as for exit_mmap(). > > > tlb_gather_mmu(&tlb, mm); > > update_hiwater_rss(mm); > > unmap_vmas(&tlb, mas, vma, vma->vm_start, vma->vm_end, vma->vm_end, > > @@ -1130,7 +1129,6 @@ static inline void vms_clear_ptes(struct vma_munmap_struct *vms, > > * were isolated before we downgraded mmap_lock. > > */ > > mas_set(mas_detach, 1); > > - lru_add_drain(); > > This is from 9c3ebeda8fb5a ("mm/vma: track start and end for munmap in > vma_munmap_struct") and I think it was also just following the pattern. > I think we can remove this one as well. > > > tlb_gather_mmu(&tlb, vms->vma->vm_mm); > > update_hiwater_rss(vms->vma->vm_mm); > > unmap_vmas(&tlb, mas_detach, vms->vma, vms->start, vms->end, > > I hope this much history is good enough to convince Andrew. With that > please add: > > Acked-by: Shakeel Butt