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 2A841C47077 for ; Thu, 11 Jan 2024 21:54:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D6B66B008C; Thu, 11 Jan 2024 16:54:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 786996B0092; Thu, 11 Jan 2024 16:54:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6753F6B0093; Thu, 11 Jan 2024 16:54:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 574326B008C for ; Thu, 11 Jan 2024 16:54:43 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2027C40599 for ; Thu, 11 Jan 2024 21:54:43 +0000 (UTC) X-FDA: 81668385246.24.0BF8AE1 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf21.hostedemail.com (Postfix) with ESMTP id AAE731C000E for ; Thu, 11 Jan 2024 21:54:39 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=xet3vbjy; dmarc=none; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705010080; 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=kUaogiY41+ofznU9sRm/iSmZURHs6Dl504WlsnAs7uw=; b=vxA4mf72uttxZcDW+2LVEcq7AbFXjIASH3Gpc1+fQ8DKoirRuJft9rlSqispwqEOKsx5xG u09r39L1kO/7XaJXxaiqFN7d6N8Q/kYaqTopg2IkPF3si58T1QAia+fuZmZpE06STU3IEW s0FsVXHNuwWapmthBCYDsdlpmVGQf9Y= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=xet3vbjy; dmarc=none; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705010080; a=rsa-sha256; cv=none; b=eQ9qlsDIlSpPJn0ByGeQisYTfmjhXV2oREIpJ5qz5sa4tKUPHP8rnoSBSQxiGwWJ5MHU30 cI60uFys/H16ev8FczGE9kFw9vkwlK8w3d6HLn0iX8LjVZ9jY2zWrfX1mnWfIQ+uWbPDqd oAWszjRfDNkeuJgTJMpFpAYwE4B5wwU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 3B89BCE1FF7; Thu, 11 Jan 2024 21:54:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 518A8C433F1; Thu, 11 Jan 2024 21:54:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1705010045; bh=5T6qmUEqSEe0y8Obv/o5UTTw7CLDO4G0csQ596TuakI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xet3vbjyx49+zfrk6MoGZp+RE0E2OV0FzrKZ0ZXmFapYLTO35UsS1r5wNfkz/t7Ci WJPKnqknMB31sMqW/lhl4CfY/mRU88A/qTLaNF0sg2Z0Eq06Ry54XJPDv0c37pz6Zs QrkOb2PFKYrp1Ufezc7HHacf5qcOkOpd4lFQwQq8= Date: Thu, 11 Jan 2024 13:54:04 -0800 From: Andrew Morton To: Jianfeng Wang Cc: Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm, oom: Add lru_add_drain() in __oom_reap_task_mm() Message-Id: <20240111135404.609af4a26d0118c0d290f11c@linux-foundation.org> In-Reply-To: References: <20240109091511.8299-1-jianfeng.w.wang@oracle.com> <1d866f1b-94b3-43ec-8f4c-2de31b82d3d1@oracle.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-Rspamd-Queue-Id: AAE731C000E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: om36gfa8mbwp58ofyftkzesmzapmof38 X-HE-Tag: 1705010079-183819 X-HE-Meta: U2FsdGVkX1/RYNl8Bptn3rQDKQA56XvfRSxg//w/hRMEuVa99Ili4RFEIlH2tlXpJjLClHCxaFDutJUfMQu2tHgNi/BjAPCSc2Q89WAeC3j2URUFJOSYxhxmcqkfpNe7AaZl7cVeN4jLekuf+KEGW6nn59svFIyOomHZ6STWCg+kgli8oJa6lJqj9X+7mW9prBA3Lhmy0oe8nCi6Gy85w4AIJuZ4dGKsJ9IqbX13qjrFiOmdthcSD1kjQs9wIfrJrxRctI8igPb6gYPKYm2uV3Odx07DgVmyNYkpTayeuf2KLzP4vHmt8/On60I6vlhr8lxgkZp+6Nm7Nkfhpk/qKPW1IImkZFXQbd1Yf1FyvMJ+sEc5CUuTVCOPZW7VMFEoHz5Uxs6kBJcxDdX8lXoWHhY/DhCeCUUUSMwDFv7vO50tqH72oXo9GaoSWOORTRSolhM+2uhrBF/NN2o7sW5AFvUXD/LLp85EKtLfBIBWgk0kPEqjHR+sONkbqtCV4dg12ibPw6ZW1owdhnqdVqsSWcJNxwlq2by5P1H9gZZ+M+b23bVsO1vkoWHSzz16odewVH9grf73LUK86w749rw57xq1Am/0L3w2mjVUgnMdd9fhtdsMdZvOA1+iwq2N1QPim3b4w1eE2pRnxjlZCQFkG/6dlhDhVAoxPxtd6IknCCigfAWcnCiUtWgg+gDBdKDEksfM3+igNzWW5XqVTE3Uj4R9YBbfYIhReEX/o9ySNsh26ogjnpZTpqMuN5kcZ/gFl7gSZv1wlwY9G970lhY4PGzYriLXVnvsP1/8OUBe3HWEFLCwC0yliKVx776k+IPx1cuVqcTQPddFovRXvO+5nIvVlQHJrzaeF2Hq3wtzXDoz0rPoGYL7QJ4iw+/PLIsoEah0AB2o7wGbozEEtP9OTbC5mYOgj9nx7kSHUFSxvdozoobz1B1X7xqId0GXNc1XbZf1AkYNqLfQHXi0MLo RN3CgR9/ f7gxo 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 Thu, 11 Jan 2024 10:54:45 -0800 Jianfeng Wang wrote: > > > Unless you can show any actual runtime effect of this patch then I think > > it shouldn't be merged. > > > > Thanks for raising your concern. > I'd call it a trade-off rather than "not really correct". Look at > unmap_region() / free_pages_and_swap_cache() written by Linus. These are in > favor of this pattern, which indicates that the trade-off (i.e. draining > local CPU or draining all CPUs or no draining at all) had been made in the > same way in the past. I don't have a specific runtime effect to provide, > except that it will free 10s kB pages immediately during OOM. I don't think it's necessary to run lru_add_drain() for each vma. Once we've done it it once, it can be skipped for additional vmas. That's pretty minor because the second and successive calls will be cheap. But it becomes much more significant if we switch to lru_add_drain_all(), which sounds like what we should be doing here. Is it possible?