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 159BCC2BD09 for ; Sat, 29 Jun 2024 02:09:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52AC46B0096; Fri, 28 Jun 2024 22:09:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DAE16B0099; Fri, 28 Jun 2024 22:09:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CA726B009B; Fri, 28 Jun 2024 22:09:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1EE7B6B0096 for ; Fri, 28 Jun 2024 22:09:56 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BBB9240434 for ; Sat, 29 Jun 2024 02:09:55 +0000 (UTC) X-FDA: 82282295550.01.D549C7B Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf24.hostedemail.com (Postfix) with ESMTP id 13C7A180010 for ; Sat, 29 Jun 2024 02:09:51 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719626984; 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; bh=7yM4phYtdZE1v/Zp+HKcyA2Sj4DsX4JS+fpvy4cpvls=; b=b1ssp2bUmvMuvwGyWlG7+sF00XMSbtAHHLGXZ7mu66Ug18EpOTiJfhHUqpQKmV5JUOn5uh zFG/AgPi34Wog1kwxw5Y5osumEqqXrFTE5Q+k+0Yce7j0JF39N2C6W792cnNEj2Ud02qnR 39KNzucGiq4AsQ6YmSz6ShwuEUKBpNs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719626984; a=rsa-sha256; cv=none; b=C1WDyvtO8kk8Qwc9asKsO/WagiNWrUb+zZGm8MHhvNWG9sPMieKW5ia4k2kPisGQOP2utJ XjNewsnXXTCIw583ELbXbhTzA9qsKAk8eLlTbW0xszb7yLtCzzDmx23UTQIzqHWoWbsAgB MEAnaAZ+2+8URuuFVLTevdwMJGE9I7c= Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4W9wjY46QJznXv0; Sat, 29 Jun 2024 10:09:37 +0800 (CST) Received: from kwepemd200019.china.huawei.com (unknown [7.221.188.193]) by mail.maildlp.com (Postfix) with ESMTPS id C390B140FDB; Sat, 29 Jun 2024 10:09:47 +0800 (CST) Received: from [10.173.127.72] (10.173.127.72) by kwepemd200019.china.huawei.com (7.221.188.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sat, 29 Jun 2024 10:09:47 +0800 Subject: Re: [PATCH] mm/memory-failure: allow memory allocation from emergency reserves To: Rui Qi CC: , , , References: <20240625022342.6158-1-qirui.001@bytedance.com> From: Miaohe Lin Message-ID: Date: Sat, 29 Jun 2024 10:09:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20240625022342.6158-1-qirui.001@bytedance.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.127.72] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemd200019.china.huawei.com (7.221.188.193) X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 13C7A180010 X-Stat-Signature: sbs5y3scopeai4a476ujk6x3yg4t11wg X-Rspam-User: X-HE-Tag: 1719626991-375260 X-HE-Meta: U2FsdGVkX18DMHUmXT8aMlLk0lrUu9IbT6ldtJ2OC1IKFJgldRbryaICMSm75aAWWAaId0iUygTTJIZd0W7ARV5dyQbyGNTH9r03D14tl9Hk4k5undxHnZdmCgfu7E2uJvP1IE7qWtZhC83pt0+l8wKF5YaTY7XHDeu3NHZpey47DBzPfXDOQipEl6ievqJd1X9wcYMJoK6cshgXsfehEJIR/7pCq+gEhqyTmbeg8aHdAS2ta/pEp4RI17LaVMlc1JL1liR7aQAegQx8JzGABxt+3XxLlxDqRe1g41iuzBJx5tSJKRbXusBeCOC7piUvvi8yiFCLCvkpyc0jFj2qXezLM1L9Txq7KtSR9NM0nCuS3wtzKzSvbqM0aWOEip2CJjQdJbcOhDUkVFq4EHFBHH9e2aHsZLON8C9W+a+BHzAIpiLEOVrl28PbFY55OUPcBkI61jGfTnOQIhPkhMDVrJvSz9dGAI0vDmwiZEHdyaDggZ9Ajl8wc3EJKKg4xmgl+qIgsq6GgVcAlNE2tusV11N42nULXaFyD0UT3ZmotlvaiYpAhW+OOC1yBCKxaFpiKpB4sxQFnbcGaZrRxx8jm9tYPnDF8uEz4wCcd5NaOjR0sfQt6iKEoC7N6+fD+a7hCjS3GA54aytmTQ2La0ibleukZoxy/O0hTzZOsI4+/uYPlPWSxJZ+xWn3fVVFYG2FyDDw3Kmu+t/JfMVUFcO6gB4fVvKUDn+xRd0J0SAsPw1pfywtsWtiJaOXiXBwtVRjjolUWpwxFFvBtJwA0VF6sD2++dNVfKl8vsY05WkAPgyt9FE4G7S4OiyDMU3f1AxZUwOuFXcVRfYuqjNlz+y3EOWAnfF5DZ1H85mc099/EATO48r3k2X3Cxj7UFrZLsj4GVjGD9E05VbggB4+Bmsg0Urlg9Dl3OT9fKK4IVzPZjbhnJDdPEShwrcd4hQ7YGELCD+8ED3i1U1iJwLoEUz 8KPQtTY2 A1iH94zdS7btWhSsIbBqMRO0LKcziDJVj5pKqAqCdAfAW+nF97755B6O4B31BrVPHQxBhUQr0Ff/JI0fVmfgjWhSF5rVB5gSyGV1rLnBeAUsal1W6LgKDTr4suu09R2WZRzh4QRH8J/UYWv95TN1hpA2F2PLa2OHs4axzai4F1+d2OpGCvoMVPt6NE+C0iv9F9zG99TEL0Qdxl/n9CMDDoJi5tu3ax0JGjouoU3SBtSka90/T45/LKGh1q1QeKkzgFuf2 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 2024/6/25 10:23, Rui Qi wrote: > From: Rui Qi > > we hope that memory errors can be successfully handled quickly, using > __GFP_MEMALLOC can help us improve the success rate of processing Comments of __GFP_MEMALLOC says: * Users of this flag have to be extremely careful to not deplete the reserve * completely and implement a throttling mechanism which controls the * consumption of the reserve based on the amount of freed memory. It seems there's no such throttling mechanism in memory_failure. > under memory pressure, because to_kill struct is freed very quickly, > so using __GFP_MEMALLOC will not exacerbate memory pressure for a long time, > and more memory will be freed after killed task exiting, which will also Tasks might not be killed even to_kill struct is allocated. > reduce memory pressure. > > Signed-off-by: Rui Qi > --- > mm/memory-failure.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index 05818d09b4eb..0608383f927a 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -451,7 +451,7 @@ static void __add_to_kill(struct task_struct *tsk, struct page *p, > { > struct to_kill *tk; > > - tk = kmalloc(sizeof(struct to_kill), GFP_ATOMIC); > + tk = kmalloc(sizeof(struct to_kill), GFP_ATOMIC | __GFP_MEMALLOC); > if (!tk) { > pr_err("Out of memory while machine check handling\n"); > return; > @@ -1931,7 +1931,7 @@ static int folio_set_hugetlb_hwpoison(struct folio *folio, struct page *page) > return -EHWPOISON; > } > > - raw_hwp = kmalloc(sizeof(struct raw_hwp_page), GFP_ATOMIC); > + raw_hwp = kmalloc(sizeof(struct raw_hwp_page), GFP_ATOMIC | __GFP_MEMALLOC); In already hardware poisoned code path, raw_hwp can be allocated to store raw page info without killing anything. So __GFP_MEMALLOC might not be suitable to use. Or am I miss something? Thanks. .