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 DAE3AC2BBCA for ; Tue, 25 Jun 2024 20:01:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B28E6B00A2; Tue, 25 Jun 2024 16:01:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 662626B00A8; Tue, 25 Jun 2024 16:01:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52A356B00AF; Tue, 25 Jun 2024 16:01:19 -0400 (EDT) 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 34C6C6B00A2 for ; Tue, 25 Jun 2024 16:01:19 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 53CBE1C13DB for ; Tue, 25 Jun 2024 20:01:18 +0000 (UTC) X-FDA: 82270480236.08.EB56394 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf15.hostedemail.com (Postfix) with ESMTP id 0F068A0020 for ; Tue, 25 Jun 2024 20:01:14 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=JiDMYVRc; spf=pass (imf15.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719345667; a=rsa-sha256; cv=none; b=dsjtQgtBaEShKuIwUyJihyfy2848+pvivPQf0Z6bSlB3c0CbXOIoA5KwA0Vk86yoG5yIKE mhnFSxEKruCPqwDKR0PP+45pgoU+fDrrgI9I/74GdrMrE2up5F4SN5eNVNzdlhyHiST01X V2tfcntkHvZ9laanW+jKmbNDMmWdDjE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=JiDMYVRc; spf=pass (imf15.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719345667; 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=6O8wvVe411kYxlKIwbFCqC7N2RUDDM89kW+TBvBDj/k=; b=VElaTDzOyCajR67K7GZU30EnpX+g4TvW++37nrFhWQRu10SppNpT8SXHIcGfB54OhzR9P4 Bl8bbaT4UXVqF0uG+UxpuNl/C5hN21YA691+AQQKqQYiZcUYfcpDHfliBIC9UJk4xnPtPy sOrlgfZOaa3trUDgT+y+i6wz8mgJk20= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id B2674CE1EDE; Tue, 25 Jun 2024 20:01:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0574C32789; Tue, 25 Jun 2024 20:01:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1719345671; bh=zZ1WlPuLtQUUBhZxGe7cmlWwIsqGh50hsMvMLAtG8UY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JiDMYVRczeaVLOdjVsTW2/yNIOijSTcrPtfBSrYKgaNz82Zll5e8FWrwGROMQhoIB u212mj/vB0yu3syi1qGVoA+yfCM+5aN/J8lrps22BZoNal7ZPR76n2COqc3KNNdQzy miIom1gHy40SPxf0W1U9sD+JSvhCfqVMPThB5IkM= Date: Tue, 25 Jun 2024 13:01:10 -0700 From: Andrew Morton To: Rui Qi Cc: linmiaohe@huawei.com, nao.horiguchi@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/memory-failure: allow memory allocation from emergency reserves Message-Id: <20240625130110.ae4f6c3265559d1b1f979a3b@linux-foundation.org> In-Reply-To: <20240625022342.6158-1-qirui.001@bytedance.com> References: <20240625022342.6158-1-qirui.001@bytedance.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: eyb4gfbxa9fqbmdexfnjqqat6f7unh9p X-Rspamd-Queue-Id: 0F068A0020 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1719345674-853171 X-HE-Meta: U2FsdGVkX1+NCkskCv2BVpbrH3PIhLTcDZ53ZqoIRdk20mIIoStLOMniPANolC72TvVY1y5ZfY+NCREijO0lAU/CefXKnnvW34xSEVRC7grEm2hXGk1uHU9sIAoiOUd0+3Lr1Mj0bavGZrS8J+y1P7EkB2yes1Rj65s/I2h7Wfd9R5beKQx27kem3g/qrFhgXetTeWSfq11gugdOZy/NNUCBdkPxwVs1nrowpVTHHdBiBXV5P8yVeZs8BflEoVgyE58CIBX9zsBFvJW8cVFI1PlS5rhBq7Ed9YE8iJzetVHpPApTw6WsRDuXLx7aOjUbc4iyisoWm/DtoujLg2EvEJ/n/aCZmHkjGyklSFt/LGLZBtUdcRmyzyyb3mMohBXzxbPXLfvrj8/fpdcpJSQ4VWgPqxLvbmrQDZnrQxChs+68lZ/CBu3tMKky1MhKjfv9GyXm/Cq9YB2dbWRghMG7y17DHohufT4pWytoqvk7rgwBC3HczngAuLDzAWb5kZ31E+yirzyj9G7gNfBmTzjH2OEo0H3uygHyclJBmRfceC9r9cZcew8DImwiVJOJ7GBTgb9QHVVTa256gPXcLsT/6gqGN18AqGRn7jAT+lIVABPrGejfhnGk4TuEi7iyynjz8lncG5xYJ0FH62UCajLLNhNwYJLwuehDkEDZOHPiAf3GayHXgcEclVJhg+w0Uc45vrFfKzDHu8sEoGmx5iWzxJXzQ4JT51Uws6Qf1YPo6H9pC/ce0pRGH06amSCw6sIek3mmul9EphhK9rjrHXKJn33WtmmbgrXyI40l2ry7JV4AA+OFVqnkN8aeqwA0su2iUD6DW9OX2ybkb7Tr84UD2ZXdGxXPWspQMgA/fsVvFus+nn9Q65NepAmpK3yPRZ3YZRZFRXVQniUH4H6lPWoSWHeyTLLljL6DC1D4gFPtbZGhj5OoXaQGoP3gS9SXmHBDKnqngClLKShvnMD7LZ4 hcFC9597 oyTb3IqBB3i2yuHBRc9CTnq0c8izmHWO8pTmDQKtqscyv26+JA4hZBTdMyE4vnjBNQuvLBf1i1a0nYF+hQ7TPZ6B+XklUxvBjGByUrUU4QC+rQKcuf3dpxq5Yuu9Lx2Ap9LEg8wfdFgwNoWU6bsMmklm5h3uNlOtNQ+juOxOfX0KHKMYvDLyH+1q/lykiclohhiJgaf1SZEh6jeqsqPv0Murq1Q49clfZKqtpyUnfqc9PXPqwhnCIoVvY2j2EFE+t1/uskAVuEdc7aBZ4wFjH2Daks6ydB0DZ3B1tMG5ohUvftplS+0uJ+DM10g== 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 Tue, 25 Jun 2024 10:23:42 +0800 Rui Qi wrote: > we hope that memory errors can be successfully handled quickly, using > __GFP_MEMALLOC can help us improve the success rate of processing > 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 > reduce memory pressure. Has this been observed to improve behavior in some situation? In other words, please fully describe the observed runtime effects of this change.