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 36BB1EB64D9 for ; Tue, 27 Jun 2023 21:34:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 848E78D0002; Tue, 27 Jun 2023 17:34:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F81F8D0001; Tue, 27 Jun 2023 17:34:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 698858D0002; Tue, 27 Jun 2023 17:34:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 579638D0001 for ; Tue, 27 Jun 2023 17:34:38 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 15BD540193 for ; Tue, 27 Jun 2023 21:34:38 +0000 (UTC) X-FDA: 80949832236.27.527BC45 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2049.outbound.protection.outlook.com [40.107.223.49]) by imf07.hostedemail.com (Postfix) with ESMTP id EEA7D4000B for ; Tue, 27 Jun 2023 21:34:34 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b="B1f/lWJ0"; spf=pass (imf07.hostedemail.com: domain of jhubbard@nvidia.com designates 40.107.223.49 as permitted sender) smtp.mailfrom=jhubbard@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687901675; 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=816Nac5snZQQ6cx9GmBzXIqna7KudkOs3bUvCKTNwGU=; b=0owlMnEocm67yAm38+rVAqd8m/Wml/3wAqx9UX06akW3baP+aZOEouAAI1KHPqLkyGk0K5 N6VFsHSf/c1bZt5UIoqQGrCRE5lL5yGTdtZgBxGdigkFkbubPDxc++Br77UQBYb8+qYiHp gbbA8fcitPX0toMgAWxdDtfaLK6a77g= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1687901675; a=rsa-sha256; cv=pass; b=Ga09erQ2b7NwgsuGYT6Zbwg5rKzDZ3NzRiDqRS85tu6vLusZ+Mda2sj4wktl9IzOzqoPiB 7n2RbseGI+700h7v1uCqbeYGF5PXA55dvGpv0xHIPFfjEOTMkeUJs1MuaYail2UI0Ol/TA dcB+qTmcrj0YUs7Qo4RjgvPG6Kowhck= ARC-Authentication-Results: i=2; imf07.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b="B1f/lWJ0"; spf=pass (imf07.hostedemail.com: domain of jhubbard@nvidia.com designates 40.107.223.49 as permitted sender) smtp.mailfrom=jhubbard@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TI4nZpZN6qLE1AstqraK1nA0ePkBdsD0ZtyCjfimkyjuwMVhDBmzmhSIcthvaSjtP8mUD+Vx+gpWaPRmFCpR8stvckvzqmHYgBVNz6PRCh8LxD+GfnptY6QbzIjGjrsdrisU83haZvHu4VL4CtFgLgfVj6sSxkfyFH2dOi1B1GHa3jFSmeLa7VuG7QhoDKsEZJO/szfarDvL9N7kbkU+2C3dO4ODRwD7z17pMy9NorY70Fc/s0qsS7PJRyjj4hzx/qptBttwrO3e6KSPnr8ZcegX1ItKsbADwZxVKcMvIDi74dFN7v+gfNfoZAwHPeGXhZ1vppQ94SSuz4czQ/xYlw== 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=816Nac5snZQQ6cx9GmBzXIqna7KudkOs3bUvCKTNwGU=; b=ZzNaqCShPMg/qH387Yb8/7ZIQ3/VxOlXfsm6EQ0aGHsLEwf6c5vmrXv+AaZo8FApqCgT+2lmtwVgzDnUp/m1RmfWoEt3yq1KtmQnRpe88ygBNx3OMOQwR0KjbHDWqY213cxM4ZAuCLQ8sRNzQLRRsfYBhEboJkofCIsM+jPwacPeGUaeatQzuS9B+/9Vo+I6X5RK3vzWDaSAo1cgiEDce/55jAdPbKl5MhULLEpEx7xHyS8mKsOi8YgM0/tszAbGEeHB3gPTU0ebOsYwmGnN/sCRzvNbsUO2XuEYGq68oVcPdGka/8qYMlFWirh/rIOxeXPDMENPH4lEwECc1jQUqg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 216.228.117.161) smtp.rcpttodomain=suse.com smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); 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=816Nac5snZQQ6cx9GmBzXIqna7KudkOs3bUvCKTNwGU=; b=B1f/lWJ0eKJvg/mjZo1GLZSG193bpWtPRM6n5IMP6Wbc2aGGDsCeaP48Dltb4z+y5Jw5JQAsJYx0tcgagxxSv8ISBmo5smoexzODLE/Fy/Nyr7oxvWxvL9wsBb1uLm7SkL3DYRvlc/hI6pG3vtB16piFZUE1Lg7VlHPWWHltnRqJrrHMg2p70odwQFUY34002MmEXy6a8EM9lp2/6T5jwld3WooEV1DqNlhmbe7n/xqJEuW5u/H4STvgV5UPQphSNbO+/h+G+4yl5Y3iiafqH4VvnaQBgpmFLPPcEeiZnZxUMHUKLUvertSdDqyz3ZR0R3n4g/8cISj126mA48HsQg== Received: from BN9PR03CA0793.namprd03.prod.outlook.com (2603:10b6:408:13f::18) by BL1PR12MB5352.namprd12.prod.outlook.com (2603:10b6:208:314::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.26; Tue, 27 Jun 2023 21:34:32 +0000 Received: from BN8NAM11FT096.eop-nam11.prod.protection.outlook.com (2603:10b6:408:13f:cafe::16) by BN9PR03CA0793.outlook.office365.com (2603:10b6:408:13f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.34 via Frontend Transport; Tue, 27 Jun 2023 21:34:32 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.117.161) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 216.228.117.161 as permitted sender) receiver=protection.outlook.com; client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C Received: from mail.nvidia.com (216.228.117.161) by BN8NAM11FT096.mail.protection.outlook.com (10.13.177.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6500.47 via Frontend Transport; Tue, 27 Jun 2023 21:34:32 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by mail.nvidia.com (10.129.200.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.5; Tue, 27 Jun 2023 14:34:20 -0700 Received: from [10.110.48.28] (10.126.231.35) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.37; Tue, 27 Jun 2023 14:34:19 -0700 Message-ID: <59ed032f-cfde-7eda-f755-9d05c15d2828@nvidia.com> Date: Tue, 27 Jun 2023 14:34:19 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v1 3/5] mm/memory_hotplug: make offline_and_remove_memory() timeout instead of failing on fatal signals Content-Language: en-US To: Michal Hocko , David Hildenbrand CC: , , , Andrew Morton , "Michael S. Tsirkin" , "Oscar Salvador" , Jason Wang , Xuan Zhuo References: <20230627112220.229240-1-david@redhat.com> <20230627112220.229240-4-david@redhat.com> <74cbbdd3-5a05-25b1-3f81-2fd47e089ac3@redhat.com> <0929f4b9-bdad-bcb4-4192-44e88378016b@redhat.com> From: John Hubbard In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.126.231.35] X-ClientProxiedBy: rnnvmail201.nvidia.com (10.129.68.8) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM11FT096:EE_|BL1PR12MB5352:EE_ X-MS-Office365-Filtering-Correlation-Id: 1beb53a7-adbf-4643-4ff0-08db77564bc2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: niO5Rmus2WB+yaMa307SMXDETX02zUWmVolWRKdVA2aZPgSRrSaCt2FUfFlvQZ9Illfp8FK/b3yE83uQGe88vBAdb2mnFKJuQO98Fv+Df7TvScGtLqEnuMQkgzv19WRwhdq3aMex+q9UinOQkj14S4k+K3nCjPQX9qqo54pmsTgkCgupcPu261jW8lmeFlLzk41L9b3u8mDpCj7mN+/RRcWjXcmsT7TOob2ci1ZcwO1j8Rgm2rqAPOVVkm4+P25W+Lu2LVVk11DUG+gE+0am8h/oIeVJe6JJLX6Nbk2UAeywXbShVWJQlJg16W90it8rnYIK/0GH4TPSiXRdZAOn+LGJ0EKDbqEq3HDCX7pnzvDS5kICZOY8qWHzAfXiXnjrU8woOqitDmTtgfZWFd9+YIsDEgEbG+fVoJhaprOxtWoOzUqqE9eZWwX/YWX2Auhr2f9oP3ZjH0WTmu4dO+UighZXdrJ/zTTFV6qc5z72CDgrxpmfHu7dxW1NaFZA+gNeNY7HYJEvHQXk5O6Kv1n5Nj8xwG9SQoiic3KUjX54OQHiIpEs/Z0aoynXZoYfzfKOn33Xkzn63CDt9IGXgqXqHGJHWgA29/zhxwwY4XiTs8qrlDJ8n0g7nqOK0gUjHU91FNIbU42KzLReyfY6pF2YCvcwrlwmFmrgpI+AvElGRrQmGiArC9nL3TV9vKxQU5Z1W8x/nCHpKkv8PeAvtfnX9UEVrh3J7X7TdubghusD31zeWfW+shU5A5J9Q7qCArVq+oLnyMP/FQa6e6CEtSqOww== X-Forefront-Antispam-Report: CIP:216.228.117.161;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.nvidia.com;PTR:dc6edge2.nvidia.com;CAT:NONE;SFS:(13230028)(4636009)(136003)(396003)(39860400002)(346002)(376002)(451199021)(36840700001)(40470700004)(46966006)(31686004)(82310400005)(53546011)(36860700001)(36756003)(70206006)(40460700003)(7416002)(5660300002)(356005)(41300700001)(8936002)(8676002)(86362001)(82740400003)(316002)(70586007)(40480700001)(31696002)(7636003)(4326008)(47076005)(2906002)(26005)(186003)(478600001)(16526019)(2616005)(16576012)(426003)(110136005)(83380400001)(336012)(54906003)(43740500002);DIR:OUT;SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2023 21:34:32.2944 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1beb53a7-adbf-4643-4ff0-08db77564bc2 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT096.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5352 X-Rspamd-Queue-Id: EEA7D4000B X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rw3eiqo66mtdc1c3q9cz1yaaby1cgsma X-HE-Tag: 1687901674-24448 X-HE-Meta: U2FsdGVkX18eQ8ADij52Ry5yrpl9DS6JOX/ZhGj4mU7aGQwiXRangbaZvR/HB4OFQHZqBiFNIJBgYTjeOUEwhTUfYQoG9047oAn7Yl7IizhmtaI8cL54w7Pxq1TNB5M22gTHjwUTHuP/x3lx1u+XLzsrAnu0LS0KNNpooeIB2g4CeyrjXXVYXuf1G9Q4xTC9zcXwQnxpucZqD0G10MVPtoDR5pZIJHYcx5jBAqJdR1BrdMIm/5xDemDLBi+EmS058ttdC8hIM0vt5djdJGgp8gZeLn5spyJCWqzamiEEYzWORsOhi0juXMPRjI1P29C9PTnHhkRXaNyJXiIfnjfqI2z8mlFLyCD0H0r40oxN3RgSIlsBcw4AjpE9PjjXZq+O4kq2vy2H3dErK/3f0wYSd832ZXpZ3BN/GXRrjplwJ3G0ryA23oDoqqOhArTYBB0fqk3ITqirlZP6MwO0doweluByDktI5GJsPJa8CmBQ39iAXm3TPoBzEzy3AYuM0Y3VGyuPyI3NhiiHcYjiuJWqF4wc4Wcg4W7jl2z0x4fU5zbejIdg6O1KhPDNbGU+bIlUs5udjKcV+PqZHeNQhAPrhy8MtFiJLh3bOO3npbLlZ2jErFJKNz+7ZihzNnAVYRH0y98P+EnAas4HBjduM6oM99208fL8E2vrGCrbYerI7NbN5qWx02iwaaoJ47c8qAECPKiwieRl6Sed6UPlkh85erzcpiRhzvf6Ts/XAya3uaHdBTbhdoJNMYo63nDSmbNZphtwPl0C+3r1lEVrMygnMJ7qcQg4/Bq6dn/7lLIFkVSQAXUHnTdZRUv7f7rHftQFhprL/Websb5gmvAFo0gbRaTFpqHvO6jtCXPEV8aULa9q0ciERISEAicP0iayWCcRRL0iLnqvp+OPWqQ6kuygKvzvqmTatBgyTVk5wntYqTLEBXCPiV971nhxX/CqO5pZNZv+GowvBmTZz7kAuKC XNSR82Lg BcF4UfIZ0LMiNq+vmeVl9nno7X6Fd7OQF+HXczE0dp2X0KgjQz38HyT6eBno3b/+mqoCOGv1/AK8q0Phuq+Ns8UZYbQWgIR8ilpnSPzc3AB29DZgTcOV/61HgF8Qw6nTzO8w9mVWBK8bRLBDcONxKbYR3B5692NKCdzDbifxUePZLG+dnwQHAKFGW+P4muRBZe5dw56li5j1M8dqKzfA9eqb6OPBsC9ybEJ/OhjsqnTZkquimhX7cYoFlB7tjtDVt8eYjT1OHokxe8wAZxfpZVVhrTcX6tAiBIH8C3tc5Lx7rGKKxDVtRPcpJmQMERoRK8NFAT3oGAS0o3gg= 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: On 6/27/23 08:14, Michal Hocko wrote: > On Tue 27-06-23 16:57:53, David Hildenbrand wrote: ... >>>> IIUC (John can correct me if I am wrong): >>>> >>>> 1) The process holds the device node open >>>> 2) The process gets killed or quits >>>> 3) As the process gets torn down, it closes the device node >>>> 4) Closing the device node results in the driver removing the device and >>>> calling offline_and_remove_memory() >>>> >>>> So it's not a "tear down process" that triggers that offlining_removal >>>> somehow explicitly, it's just a side-product of it letting go of the device >>>> node as the process gets torn down. >>> >>> Isn't that just fragile? The operation might fail for other reasons. Why >>> cannot there be a hold on the resource to control the tear down >>> explicitly? >> >> I'll let John comment on that. But from what I understood, in most setups >> where ZONE_MOVABLE gets used for hotplugged memory >> offline_and_remove_memory() succeeds and allows for reusing the device later >> without a reboot. >> >> For the cases where it doesn't work, a reboot is required. That is exactly correct. That's what we ran into. And there are workarounds (for example: kthreads don't have any signals pending...), but I did want to follow through here and make -mm aware of the problem. And see if there is a better way. ... >>> It seems that offline_and_remove_memory is using a wrong operation then. >>> If it wants an opportunistic offlining with some sort of policy. Timeout >>> might be just one policy to use but failure mode or a retry count might >>> be a better fit for some users. So rather than (ab)using offline_pages, >>> would be make more sense to extract basic offlining steps and allow >>> drivers like virtio-mem to reuse them and define their own policy? ...like this, perhaps. Sounds promising! thanks, -- John Hubbard NVIDIA