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 43064C001DB for ; Thu, 10 Aug 2023 08:42:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FB496B0075; Thu, 10 Aug 2023 04:42:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AB3D6B0078; Thu, 10 Aug 2023 04:42:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84B4B8D0001; Thu, 10 Aug 2023 04:42:10 -0400 (EDT) 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 6EBD96B0075 for ; Thu, 10 Aug 2023 04:42:10 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 30662A015D for ; Thu, 10 Aug 2023 08:42:10 +0000 (UTC) X-FDA: 81107552820.19.933CA7F Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2057.outbound.protection.outlook.com [40.107.220.57]) by imf17.hostedemail.com (Postfix) with ESMTP id 78DC04000B for ; Thu, 10 Aug 2023 08:42:04 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=WdE7iXQt; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf17.hostedemail.com: domain of apopple@nvidia.com designates 40.107.220.57 as permitted sender) smtp.mailfrom=apopple@nvidia.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691656926; 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=jxodEUAYeDuMuQBrg0Mtk+t5gpuSw54Z8tV9HxBx8wY=; b=bh3I1sCAdy4Z/0u2hYMxbWZAFZcWbKREXoGQyPn6zv85pL8te/uEJcXMwV4Xo/CPacxdt7 ENGKjrJK/NmROiMPJ+lUmwBm22eKhomEozpVDZ6pOR8a8QpubpHSBeIS1oO9fljQuqJt/B srQDjDXsGemP5WNb85KpGDlGsi+vtfk= ARC-Authentication-Results: i=2; imf17.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=WdE7iXQt; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf17.hostedemail.com: domain of apopple@nvidia.com designates 40.107.220.57 as permitted sender) smtp.mailfrom=apopple@nvidia.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1691656926; a=rsa-sha256; cv=pass; b=q/dz+ImtyngF0JTT2J/oUHn03rPXqSY9JB4+PIh3HLDQLEoYXX5NAowwvAxxGpFZhttvqR gVDjd2R7p+ELrXpFw6CQPGG5pIDJgKSmEskClxbU35uz3vI0VX9/L1kwfUtjib5kZfw6hu 0Uk/0NCJr9TfO4DRYte6HUG7BQNiWC0= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dKKAEgUyO6ictCwWmuxLwnQtyUwfkDupaS7Lbjak2nJB8tzTpe+4QCUAPrrmY1VTv+3aLk7G2w8C8JJJ1J5ydceKvvj0hVRRZS3UfbwOk1ubvlBl/Q64tV8gUb0ATTvNYrRkusbJazPajQbrpQtIe+TV1ef0k/iMv+sppXT0EOC09SYQS6mKpxS6f1v1fzIj2H6jt1TW9kncoxehXp3QpZXLhVQwwaBFOQiKmskl3lNonsuraUyOxwKIBC6Ca6yuc+F8CgB0EaO/KX7f6aH3YL1NLjGOJK9RREbMzarFOzmvX3X0LdrieFJ8j65sxjolHVLmKZ8qq4DuRPPhSzlSaQ== 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=jxodEUAYeDuMuQBrg0Mtk+t5gpuSw54Z8tV9HxBx8wY=; b=L+KkOzKojufMbWIbReprQdrdzZNo/nRkU1nc/KzUhHCgIXQg9vQoWsI0tGyT6xwbFKl5te2+o5RXAcpC7eIqcAR8M8rvm/nSGdEW4vILOKCopMqF1z0kkXNoM5mJnjHm8j6REBcWd1OZj4VRsuhrMiBwzdVwdDLNV4SkiYwpI+wT7ZvkRzrQurbOk/mZL+nHG1S35plxkuxNlqpsiaX9wMHJPA3gd0dg6kZcZEdGMwk1z/zEy0NGz+wYzcpgnvD1oq3uiwMV8jdgIDtCIGJOL5V6oyybzR17sf15oYH7NkPUANQuU8Y6Kr3Ji1BKat7xOH9UvuS06ClUAU7GZdw8+g== 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=jxodEUAYeDuMuQBrg0Mtk+t5gpuSw54Z8tV9HxBx8wY=; b=WdE7iXQtJj3nAyaQsGiGjtpaOtPFbnbnqkZJYAVOK/HEOC835gEV0srcLR1vJaZhPz00zo3tkobjESuyABKqj0Cm5E7dgqnqeCNb7EX08/GWn9qIrHAjR98zoxIFjF+gGoYu2SUnEG9mqGrZUwcvnjtEwRtkLbq6dgxEVDEbOxXDGrMj99v6AqGMGDEZXVvaWTg4eolFPyWwXmjDHDZDE7xJvS23SASSwHf7vcYyg69E896WFk/AY6AAVQd9fIc2OhIr2lpf8LchsbHG43sYiohHncg7ZqPJaRE9AuYb2c2DucNmZCbavxMyWHawFN4IhuKJj5uSZrqCUeKux05z9g== Received: from BYAPR12MB3176.namprd12.prod.outlook.com (2603:10b6:a03:134::26) by DM4PR12MB6087.namprd12.prod.outlook.com (2603:10b6:8:b1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6652.30; Thu, 10 Aug 2023 08:42:00 +0000 Received: from BYAPR12MB3176.namprd12.prod.outlook.com ([fe80::b2b1:755a:a175:c160]) by BYAPR12MB3176.namprd12.prod.outlook.com ([fe80::b2b1:755a:a175:c160%4]) with mapi id 15.20.6652.026; Thu, 10 Aug 2023 08:41:59 +0000 References: <20230807063945.911582-1-apopple@nvidia.com> <20230807063945.911582-2-apopple@nvidia.com> <9de42ace-dab1-5f60-af8a-26045ada27b9@arm.com> <87leen2f4y.fsf@nvdebian.thelocal> <460ae27d-987f-ec45-9d37-1566f7c4f576@arm.com> <87fs4sal9n.fsf@nvdebian.thelocal> User-agent: mu4e 1.8.13; emacs 28.2 From: Alistair Popple To: Ryan Roberts Cc: David Hildenbrand , Andrew Morton , linux-mm@kvack.org, mhocko@suse.com, jhubbard@nvidia.com, ying.huang@intel.com, osalvador@suse.de, baolin.wang@linux.alibaba.com, ziy@nvidia.com, shy828301@gmail.com Subject: Re: [PATCH 2/2] selftests/migration: Disable NUMA balancing and check migration status Date: Thu, 10 Aug 2023 18:23:29 +1000 In-reply-to: Message-ID: <87edkb8f1r.fsf@nvdebian.thelocal> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: SY5P282CA0085.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:201::16) To BYAPR12MB3176.namprd12.prod.outlook.com (2603:10b6:a03:134::26) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR12MB3176:EE_|DM4PR12MB6087:EE_ X-MS-Office365-Filtering-Correlation-Id: 7ece4725-6c18-485a-c620-08db997da96f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: RWJBs6o42tqauTHplCD9vr82/2+nYl/0ddM3FrsrDEK3giS7CauWaH6gqjoVpbjTwrTHKpxxgNumE9SlwQ5AnjY6eLLhsalVa+mbEXpasCkXJkxVoqDT/VgoTgaP6D4sYvRInkpwI+BBFQCLnSJ5RilhF4WpVbf4D6tf4IY7efJY1YGAua9HghQEKmSvSST5zAabABDQ83guCw/2BXycF7c+USawvpgFUyAFbackFLvxL4aVqS6kYggU4UzNh5kLdaft5hkKmNkXsAg5DNx9LeCIcdmUaeesx/5mptuEyuIRVjipnufDafeMr7KNk6h40+nN2w0pc47e7kA85EsHXDJF//Vs3c5iAPm78FIjpwhfQvgCI7s7oKnmHSUE3FgBHYPpPBY1nfm7KQat/7mfYM5jjCQcKWrHwH3kHsQHxOp8lfu6rFh3Qipg7j8YGoCum52U75znAHCtt/Fh74opsgtSVXXlibQLCfN74kwcVKps+3JhGLWwAMsCgQChuTfoz/SxQnNXOjPt5uphHh1h6fC6CvqCyIrsJDMz5/9HVoWQPQYa2wYRIsYmwdRyly9/NtBoL+5xIMIFz5qU5IhkrHdcABneo0N5tYV5lAvrIRI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR12MB3176.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(39860400002)(376002)(396003)(366004)(346002)(136003)(1800799006)(186006)(451199021)(26005)(478600001)(6666004)(66946007)(66556008)(66476007)(6486002)(6916009)(54906003)(6506007)(53546011)(966005)(6512007)(9686003)(4326008)(2906002)(41300700001)(316002)(8676002)(5660300002)(38100700002)(8936002)(86362001)(83380400001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NnpkVEJ4WFQxaEhaUUZrS2NKUCs1UDhwNmN3cTVSTGU3R2piZXplaHJhb1dl?= =?utf-8?B?cUNMTDRBSW1wOGQ4N0FGTHR5Mm14NUZzaGlvZTNTZDhsem5qWTBmUGRFQkhC?= =?utf-8?B?VFBidDRzdG1mZG1jTTBHZVJkeU1RUnpnaExLTHF6UnJrZWUxUmRIWlo5aVh1?= =?utf-8?B?bEZXVGxES3Y3Q1VXS0tOK1h5L2w5K1A3a0l5cEh1UTlKcVp5U2g1ODk0VHBO?= =?utf-8?B?eEN1SGlHTUhZS1V0QjRuZlpRanJqeDR1TEhvN05hcGx6RUlyRVpRb280UVJF?= =?utf-8?B?R3pMY0RrNzMyMGVvNHlpNjJWU2R5a3B5emJ1Rjh4TkpJYkc3SU5LODVpTkha?= =?utf-8?B?UEd4R0kwb0tsbDY2NEV5OVZOZGV0Q2xrMk9hU1JUYlZvTlhkbkZuTzB5MS9M?= =?utf-8?B?Qk1GVU9nem5PaExvUFpjeVNFRkF0UHZHdkxrcFVselZRWWZ2MU9md2d1WEFN?= =?utf-8?B?WmhtYWQrUGFLMHpZb2RNdHgyN2RzWmdUTm5GU0h6bmVhckxsVVVYSThMay9C?= =?utf-8?B?WGl5VUJDSUFKYjFFdDhrVDNOdWtzUnpKbTZmMk4rN0tYUnJOaXBYZHBQY3pQ?= =?utf-8?B?QU9XZklwTGF6ck5pRnVuK0xuL0RvL0RRamZ3T09rWjRUc0thMVlKRURRclB1?= =?utf-8?B?ak9kZjBlVEc5UDlKazRRSGJnWUJsQVhHZ1QwREZNeTVqWmR6aEZXVDdpV3Nq?= =?utf-8?B?cklId09HemoxSlpnOEIzS051bzVJc0I0L3FsY3NZWFlGNzgxbXlpOFZ4Wm1K?= =?utf-8?B?aHM4ZTVGUWdpdXFhdy9NUHhha3NPeHN2MGJzY1Y5c1hDQjkzdkdUTkxPZzlS?= =?utf-8?B?cXEzd05oc0hKMXVjNDZwdHdhbVlCQmRQb3dSeVd3aFhWTGNBaG1aMmQxSkpJ?= =?utf-8?B?alJsVWxOdEFBU2tRK0UzRFdMbi9Ia3crT09Bb3VPRVVCNmJkR1JVUDhQdUp3?= =?utf-8?B?QW1Dd2h5OWhmb0k0NmMyRklGcjhqTXpGQ2xkNUp0V01zOVNpOWlENlY0Q1p2?= =?utf-8?B?ZnhSTnZobXd5b0U4MEFxR1BVNHZDZlpZcG1QMXBma2JPZSs5RFE1VUhMb1No?= =?utf-8?B?cC92bUtvRXFLUkl5Qk01Sk9nNnVNemxyRFprMlpPZW1OZFBDaXg3RUQ3Qll6?= =?utf-8?B?eVo0SStGeFUvTjBPanNKR0dja1hRUzdRQXhIclFubTlrbGJYaldldmFaRnRh?= =?utf-8?B?L3R3NUlmblV3b3UzbVBUMUNUUlJnYjJ5M21sdDVkbGVwK2U1TU1uZFRqaUQ4?= =?utf-8?B?VEhkNGp3RVRSSGlGazJWR0RTTjYrcjBDWmg0T3VESFMwMEVGOU8zYjhKclBD?= =?utf-8?B?RTdSYk0xZ2FQZS94MkpSaEF2dTZraXJVZmNxTi9HVE9xbzBHemh6RmtqZTN6?= =?utf-8?B?dlRSZlA1RFRZRkpFbU1jWDAxK0ZZb0VSdEp4UUpnamtIVzhZWkJzQ1R1RWp2?= =?utf-8?B?OE1WcmQ2bEtGRGpqNmlJZWpadE8rRlYxeDdkWVRQUUQzWHdlajBSTDRtUG1Y?= =?utf-8?B?TTVBcEVKZFM0Z3lYSzFoRjBZUEdwSFd1TVFGQ3lZRHFIMERjdVhvUjdXbjRC?= =?utf-8?B?YnE2T2paRlM4UVN6Z3VycHUxRk5Nb2RCTFVnZHZza1EvQjFVQzJQT1JtUzUz?= =?utf-8?B?U2VyaE80MnBhQWsxV01qbHJIcHgydDJNS2xZVm9UeWJHMldoNGNjSTV2WDVI?= =?utf-8?B?aW9wdGRVQkR4eFcyWTU5cFI5cktabnE0VGZFYTdMeTB6SWQzaVhrV1B1LzFS?= =?utf-8?B?eXZUaHVLRGY3UGthaTBRcFlGNXhkRWRpK2hHUXVsVkdFTzkvVnVHZHdWUDJY?= =?utf-8?B?cjFNWkZVU29ZS2RxemdGM3FVWlo1a2pXcUIzMmY5cm1ZdCtFT2U2R3liciti?= =?utf-8?B?eXYrNHpwUThtWWh0YmFCWW94aUFjUDM5MitlbmYrUmIyOEdqaWt5aURYNlRZ?= =?utf-8?B?bU1qWUtxOGJLWVRLZ3h2bENXODJLYVZTeFdidUVuTm9QbHU3ZEpsUERVV2pl?= =?utf-8?B?QXJSVDlrT08vWTFMRU5Wb2VKOEhWRkQ2L0JDMlBETHpISjMySFJwa3NrVllN?= =?utf-8?B?bGhmaU1rTTk3cnBnTTFuNmk5R2VPWGVWY3JYOUhtbEoxUUMvcmdNVGNSN1NJ?= =?utf-8?Q?Mtl8fc5eDt0iCtJjfYNW/rbhp?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ece4725-6c18-485a-c620-08db997da96f X-MS-Exchange-CrossTenant-AuthSource: BYAPR12MB3176.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2023 08:41:59.9356 (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: fS7gkwpm23i6EnwVe2t0I+juDNUS/oAaw/qeKUwV0oxHR3ZPD8oM+atpZaPKCRfG2RFhivnMRpUnJJo4qLUHhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6087 X-Rspam-User: X-Stat-Signature: k8o8szjqzyynrbccut7fb4tmtz6s4ujw X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 78DC04000B X-HE-Tag: 1691656924-50641 X-HE-Meta: U2FsdGVkX1/gPfm019P48uLV2wZvS7A8mdDSNKd7W+17Q/ttHGiy/wNPnp0JL/659Y4eqOU9+LaONCc6ydXZdjhuesQMIhZbgN/yt1+poTTe3i5jQBYKntLAHkh8BrdPYdxcKGQYTIOqxWUOjsu8stzejSLBJvG+vYccAqau73WzjvgWlGaxK9K78t/ogq7JAhVIMKFy254NF1n6qgpjfYv1vLLac+jvVoxAd77IBQD4a1MCuyuM4paNn/VnidceVnh6Du/mn4D+K6ryFvDLEsFaS2rX9h64ZscYgZhhL3H9zPc2dOfrMHZmpxKaDoBecrv85QChg+eHvzHMsBRFNNCMpGWsz+Mrjya+3a++cnhcPSHF6mkQFbKxgdaJ33UJ+6fbkb9vWtCBoPtanALc9vojHpgos9Y/IZWWbTCFxm96JfRDSNElDuWpBsQj8d3+3Kr7pTyB5wr3o3deOOFT9XEHBMQn8WoUmDHmsvlQ7NY7acfO72kgAzC2vGvTaFs2Nt+xajWy89m+3UTwtX2LvP3zE93AzPLCanED030U+T750o1tRf1HvgvBpgjUqYYuCbgzdFU00LIndYDhIctvnF3NRoeh7D2OMCEm6CBsSgPSbupDd9WmlRUaHWVKMjhbjEkoej2J4pgxNIU/E+8aEs93CK7KLT42k471vz4mZ/vh3ja4U52j2Yg2tmRLzKVsPmDZoU5hKpPxnP7E7cWkQA2HxtGBtTSYb035SAhcj4+VX3CFqppn1t2LttvdlYGceXjZYFMixgRXVHnOn6coPLL6hVmz76nKZ6r8aQ2NHW9OJdRBwyibdtFyNqPe0OVw658seTUpN0UQplW3HyqEE7JGif2f22f2r/HiS9kTFe+Ag7nvHPUU45IMZNI8hrJDQ9cMcSJoEbCRok0gD4yiVO8FIqCsX7K//8iJI+QsSkBL/v6GaxWWToS+uLFHU6VY7ACmIwIO/IlXT7zTDsH nYkAeDDI Aw22ANaTjxHW41RXiCPLU1EcgBYad9DSKGbPbovMKTdcArC2FlD/vieVMOEi7e54Jbu+egIak66z4hiEswfVNvkd5rTD/+e7Ar19nHa4hEWXJ0fprxUwf+Yz+hIsss5i52QAer9CnQNzDyE1NmrjfVtCO/COgeHy7LUgsIjB627T1LwJJtYkrmff0VMErzpFXUkK+zh8ab8jeUSml+W/hrSWQjkqF0Q5pXKut5jrPc1CPM77JksngG2pEtl27xF3ajHS9L6Qq3ARxAoGmr8KnCvsgfOhqN7skNwzuPqxKHchbl2p/QR3Z8ZDgZsNs83sUsskTW8oX0ZE6V/C59qrJmdjjDTFQ7bVg5t2yLYrAzvOQkiN5UOUgN6q58BaCkSkg1g2/DOiGVFiBxVuhiSSpNtsKCZBum13hJQ6h5YQr3ZtFCRCvXT6eNJwiMXn94PSjkZhUoSp9tu/D574NetrgzixT9kQrxvmBT1DUrUtrdgL5OJ0evobIcQzycubQ3fyuq5z0lSV7ghF41FeF6+04JO7Dl/ZP0t+BEbBr 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: Ryan Roberts writes: > On 09/08/2023 10:34, David Hildenbrand wrote: >> On 09.08.23 06:21, Alistair Popple wrote: >>> >>> Ryan Roberts writes: >>> >>>> On 07/08/2023 13:41, Alistair Popple wrote: >>>>> >>>>> Ryan Roberts writes: >>>>> >>>>>> On 07/08/2023 07:39, Alistair Popple wrote: >>>>>>> The migration selftest was only checking the return code and not th= e >>>>>>> status array for migration success/failure. Update the test to chec= k >>>>>>> both. This uncovered a bug in the return code handling of >>>>>>> do_pages_move(). >>>>>>> >>>>>>> Also disable NUMA balancing as that can lead to unexpected migratio= n >>>>>>> failures. >>>>>>> >>>>>>> Signed-off-by: Alistair Popple >>>>>>> Suggested-by: Ryan Roberts >>>>>>> --- >>>>>>> >>>>>>> Ryan, this will still cause the test to fail if a migration failed.= I >>>>>>> was unable to reproduce a migration failure for any cases on my sys= tem >>>>>>> once I disabled NUMA balancing though so I'd be curious if you are >>>>>>> still seeing failures with this patch applied. AFAIK there shouldn'= t >>>>>>> be anything else that would be causing migration failure so would l= ike >>>>>>> to know what is causing failures. Thanks! >>>>>> >>>>>> >>>>>> Hi Alistair, >>>>>> >>>>>> Afraid I'm still seeing unmigrated pages when running with these 2 p= atches: >>>>>> >>>>>> >>>>>> #=C2=A0 RUN=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 migration.shared_anon ... >>>>>> Didn't migrate 1 pages >>>>>> # migration.c:183:shared_anon:Expected migrate(ptr, self->n1, self->= n2) >>>>>> (-2) =3D=3D 0 (0) >>>>>> # shared_anon: Test terminated by assertion >>>>>> #=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FAIL=C2=A0 m= igration.shared_anon >>>>>> not ok 2 migration.shared_anon >>>>>> >>>>>> >>>>>> I added some instrumentation; it usually fails on the second time >>>>>> through the loop in migrate() but I've also seen it fail the first >>>>>> time. Never seen it get though 2 iterations successfully though. >>>>> >>>>> Interesting. I guess migration failure is always possible for various >>>>> reasons so I will update the test to report the number of failed >>>>> migrations rather than making it a test failure. >>>> >>>> I find it odd that migration always succeeds for the private_anon and >>>> private_anon_thp cases, but fails for the fork case. I guess there is = something >>>> about the page being RO (for CoW) or having higher mapcount/refcount t= hat causes >>>> the migration to fail? >>> >>> But the fork case uses a shared mapping, so there shouldn't be any >>> RO/CoW AFAIK. A higher refcount than expected would cause migration >>> failure, but there's nothing I can think of that would be causing that >>> now NUMA balancing is disabled in the test (that caused migration >>> failures for me in the private cases due to the concurrent migration >>> attempts). >>=20 >> Yes, we do have MAP_SHARED | MAP_ANONYMOUS, which is just shmem with ext= ra-steps. > > Yep my bad - not reading the code properly. I assumed it was private beca= use the > other one is. Not a problem! >>=20 >> In add_page_for_migration(), we do have >>=20 >> =C2=A0=C2=A0=C2=A0=C2=A0if (page_mapcount(page) > 1 && !migrate_all) >>=20 >> but the test seems to always specify MPOL_MF_MOVE_ALL when calling move_= pages(), >> so it should be ignored. >>=20 >> It would be helpful to dump the page when migration fails in that case. >>=20 >>=20 >> Note that in add_page_for_migration(), we perform a follow_page() that u= sed to >> accidentally honor NUMA hinting faults. Fixed by >>=20 >> commit 3c471b04db7604974e3bea45e2d9c7c27a905536 >> Author: David Hildenbrand >> Date:=C2=A0=C2=A0 Thu Aug 3 16:32:02 2023 +0200 >>=20 >> =C2=A0=C2=A0=C2=A0 mm/gup: reintroduce FOLL_NUMA as FOLL_HONOR_NUMA_FAUL= T >>=20 >> in mm-unstable. > > This fix does not change the behaviour of the test; it still fails. It fixes the failures I was seeing for private_anon with NUMA balancing enabled[1]. Clearly there is something different between Ryan's setup and mine because he doesn't see failures for the private cases but I do. However I am still seeing failures in the private_anon_thp case with NUMA balancing enabled even with the patch. I haven't had time to dig deeper - perhaps it is expected. From memory concurrent migrations can take extra page references which could be upsetting things which is initially why I figured it needed disabling. > HOWEVER... It turns out the test has started passing in mm-unstable due t= o a > commit after this one. See bisect: As I said, I've never seen a failure for shared_anon on my setup so haven't replicated this. Hopefully I will get some time to look more closely soon. [1] - Note that requires changing the test in this patch to still pass 'status' argument to move_pages() but remove the mbind() call that disables NUMA balancing. Without the status argument the test passes with NUMA balancing enabled anyway with or without the patch from David. > Note terms are inverted: > good =3D> test *fails* > bad =3D> test *passes* > > Initial bounds: > good: 3f943756e8b3 =3D> commit suggested by DavidH (test still failing th= ere) > bad: 84d9f657acae =3D> mm-unstable head as of a few days ago > > All of these commits are from mm-unstable; none are in v6.5-rc3, which is= where > I originally reported the issue. > > git bisect start > # bad: [84d9f657acaecc43dc52f25d52230db85fd5ffdd] mm: move vma locking ou= t of > vma_prepare and dup_anon_vma > git bisect bad 84d9f657acaecc43dc52f25d52230db85fd5ffdd > # good: [3f943756e8b3e0b5d0ea1f3087658eb559b0c7b0] mm/gup: reintroduce FO= LL_NUMA > as FOLL_HONOR_NUMA_FAULT > git bisect good 3f943756e8b3e0b5d0ea1f3087658eb559b0c7b0 > # good: [7dfbad370c66f35789d193a758575d31aabd25a4] selftests/mm: optional= ly pass > duration to transhuge-stress > git bisect good 7dfbad370c66f35789d193a758575d31aabd25a4 > # bad: [fc99f767390266b5436575c00445d4445f6c9be6] mips: convert various > functions to use ptdescs > git bisect bad fc99f767390266b5436575c00445d4445f6c9be6 > # bad: [af89742c0bf319979e00cfb066ead6b510f3e296] powerpc/book3s64/vmemma= p: > switch radix to use a different vmemmap handling function > git bisect bad af89742c0bf319979e00cfb066ead6b510f3e296 > # good: [dfebce290a7b44985eda4ddd76378cdc82e3541c] maple_tree: adjust nod= e > allocation on mas_rebalance() > git bisect good dfebce290a7b44985eda4ddd76378cdc82e3541c > # good: [9517da22a74a49102bcd6c8556eeceaca965b0a6] mm: move FAULT_FLAG_VM= A_LOCK > check down from do_fault() > git bisect good 9517da22a74a49102bcd6c8556eeceaca965b0a6 > # bad: [5ec6b3644e50d859ebf4cba5cc29cfbda0e6d109] mm: change > pudp_huge_get_and_clear_full take vm_area_struct as arg > git bisect bad 5ec6b3644e50d859ebf4cba5cc29cfbda0e6d109 > # bad: [bbecc62bae72ec22e4276464a5ef359511923954] mm: handle faults that = merely > update the accessed bit under the VMA lock > git bisect bad bbecc62bae72ec22e4276464a5ef359511923954 > # bad: [2132f14c5bc1b10ea964ab89bd6291fc05eaccaa] mm: handle swap and NUM= A PTE > faults under the VMA lock > git bisect bad 2132f14c5bc1b10ea964ab89bd6291fc05eaccaa > # bad: [8890e186b3470fc690d3022656e98c0c41e27eca] mm: run the fault-aroun= d code > under the VMA lock > git bisect bad 8890e186b3470fc690d3022656e98c0c41e27eca > # first bad commit: [8890e186b3470fc690d3022656e98c0c41e27eca] mm: run th= e > fault-around code under the VMA lock > > First commit where test passes: > > commit 8890e186b3470fc690d3022656e98c0c41e27eca > Author: Matthew Wilcox (Oracle) > Date: Mon Jul 24 19:54:08 2023 +0100 > > mm: run the fault-around code under the VMA lock > > The map_pages fs method should be safe to run under the VMA lock inst= ead > of the mmap lock. This should have a measurable reduction in content= ion > on the mmap lock. > > Link: https://lkml.kernel.org/r/20230724185410.1124082-9-willy@infrad= ead.org > Signed-off-by: Matthew Wilcox (Oracle) > Reviewed-by: Suren Baghdasaryan > Cc: Arjun Roy > Cc: Eric Dumazet > Cc: Punit Agrawal > Signed-off-by: Andrew Morton > > mm/memory.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > It's not really clear to me why this change should turn the fail into a p= ass > though... Perhaps migration tries to get the mmap_lock and if it fails, t= hen it > skips migration? > >>=20 >>=20 >> Maybe that fix does no longer require you to disable NUMA hinting for th= is test >> case. Maybe you're lucky and it resolves the=C2=A0 shared_anon case as w= ell, but I >> somewhat doubt it :) >>=20 >> It doesn't really explain why the shared case would fail, though... >>=20