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 21493E77184 for ; Fri, 20 Dec 2024 02:05:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 477676B007B; Thu, 19 Dec 2024 21:05:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 427A16B0083; Thu, 19 Dec 2024 21:05:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F0606B0085; Thu, 19 Dec 2024 21:05:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 11F516B007B for ; Thu, 19 Dec 2024 21:05:09 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A7E921A0637 for ; Fri, 20 Dec 2024 02:05:08 +0000 (UTC) X-FDA: 82913692302.20.EAD43B3 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf05.hostedemail.com (Postfix) with ESMTP id 18BF9100011 for ; Fri, 20 Dec 2024 02:04:00 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734660291; h=from:from:sender: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=iL5lUCQrsCjSO0niMaIP7pJlnidDcGn+V8QVI8LgS08=; b=u/ucx9vBTPOvjWHoRaQEdkjoJnBvtel/jyP4u7Qj9E+z4Zad5IrzCMgoA32ahKEoo0Eeif dHGLGn+zpEJtx03jfJbSv6g4COAjK1AOziGgAFlmOOCMc2X68hCBQICamG9FYpvLU2E+wb 4QX0HKdhraCsVtWrn5R3+sf8yvzS+aY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf05.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734660291; a=rsa-sha256; cv=none; b=IqsFfnE7CT1wTz2LPkKwhL19P3r6s/vnmhy9dbfsZHoyjVz0BouYpygxlDPvOADsPQpQzy kn3Aim7/X7PGjmC/CqGra8v5F4GRfaejOilpBzXkKATtiAje9jx8s9Z9eAEKfy5e7KSu1i xM+CAp215IpGBJVwmCHrpZDf1EaY2pk= Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tOSK0-000000006zG-3ppO; Thu, 19 Dec 2024 21:00:56 -0500 Message-ID: Subject: Re: [PATCH] mm: remove unnecessary calls to lru_add_drain From: Rik van Riel To: Andrew Morton Cc: Shakeel Butt , David Hildenbrand , Chris Li , Ryan Roberts , "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Date: Thu, 19 Dec 2024 21:00:56 -0500 In-Reply-To: <20241219141429.165830ca3f405d5fd08be353@linux-foundation.org> References: <20241219153253.3da9e8aa@fangorn> <20241219141429.165830ca3f405d5fd08be353@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.1 (3.54.1-1.fc41) MIME-Version: 1.0 X-Rspamd-Queue-Id: 18BF9100011 X-Stat-Signature: 6yrb6wb1cggcebshpfk7g6pqrsdrp11x X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1734660240-935575 X-HE-Meta: U2FsdGVkX18iuFZppqdqSCpBLM8KrcL9bx50rDsRoBpTypPm4+pLIasakyPvegnt824ZTpQFkgHGIznis2pnrQEdt8mtE5Wru0IGBismBBos8bH3kJw8COw9pjvaL8pJiaWE/WnHiMKPQUnYvPh5MjR7QqkGgYUNjwdPpCJLafS9PL6VFjnr5wcdYzBmu0LWqi0XC1RJa8c34ZDzfm0ekYZ9ecXy+FCjHgBRs1kaLPsxwrvs32PDzx14mCkh9xuifKHKob6ZQ+btIvLTXSyJD+jLN9pnscE5bRo+G5LECgKBpo3P+G2XJpodUZGoRCwLCmUIiGNfkZBVEGc87jqMPHCAWJw98MwNqzG10iqY2OL6ts6Dkz3ALVLU1LiTp2K/jVBAn4X2wHZ0wg5VN4JskMXDABdn0+HuoV7ct1rM0OlQPFvx7MheOHn9lkUZ9bnn2LvY8dxSmm9VwP7RkLh6Cnr+3ZkZHAspELPFIxkLi0pUtF7lMO4VMBhF1IKipBcJENVW6YK/Z5myvVYZZRhsG7ZSy/jxwy/bUkWfvae89sAqAIAV9L42PEN+SU+YSmYPHPOhUZ2PYG/q8FClGWNnr/KtgPSO5ZJ+kV46+pJewnqogT+JaeTwDY55fN2lfQiRcHKSShd3Y/Pqnb43mkOGJYRYmcrXy+MMSUMRps9z294+1+DHv48YLxhZs0DLsiLnR10MxVvz99sYheTe/Pu+R8+8oto9scCrPZvn4t+8aQcJBncrnSHp1Q/L5kFhiZXkUY/dqinF+k/GUpoBXuaUE0ltGJCb/pr/n+rSGqz8fdpj2PimmJGccikg5NIS3XgwQdHq8YFj60YDbWgaWCptDJszAGjPD5sS1ifpNDHFyUNNUxiLYEq1UdQGUw3xDoiYaCexLCmENEy1UTdfgtuemozWtOqfV8CQ36Uoykimt2UIIezwqwPypzFnW8BHMu+dAK41LOUtOECBblIrA+v MRKFTcKm zukDnI/BD2V4GnFJcucnkx4NsklsS11FT82QtEWHx9DEPBfdivJ4fUaoNMpgM3Ganv+f6e0OTeIGPv1SCaYfuhOjEzfdaqF6Do6pS3RyPqtkv+Ri+ECO3Y2Lcn9L0hV1SMyNKESSHJrr4jHNCFzi4quxGgJD+hpwdmjw6A+lio16FM12eR7seYo1bfbm37xcBF02HFHU8n2DPGvmp1Y4sJ9/4E2pn4oIM6R2UmPVyfyYLOijz2DnhyFVd3bkMgV2qVXm4xWeOGKjI/YRhE43+FuCIn9fLdiz3HXHLzPaIjxg5EM0fJeAYUfiFTsNUdL533zVtroykWsbQ5V3nfd1EmhFE6KelviejXajdQMM1zf6Q67JPMmDEVZz/8A== 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, 2024-12-19 at 14:14 -0800, Andrew Morton wrote: > On Thu, 19 Dec 2024 15:32:53 -0500 Rik van Riel > wrote: >=20 > > There seem to be several categories of calls to lru_add_drain > > and lru_add_drain_all. > >=20 > > The first are code paths that recently allocated, swapped in, > > or otherwise processed a batch of pages, and want them all on > > the LRU. These drain pages that were recently allocated, > > probably on the local CPU. > >=20 > > A second category are code paths that are actively trying to > > reclaim, migrate, or offline memory. These often use > > lru_add_drain_all, > > to drain the caches on all CPUs. > >=20 > > However, there also seem to be some other callers where we > > aren't really doing either. They are calling lru_add_drain(), > > despite operating on pages that may have been allocated > > long ago, and quite possibly on different CPUs. > >=20 > > Those calls are not likely to be effective at anything but > > creating lock contention on the LRU locks. > >=20 > > Remove the lru_add_drain calls in the latter category. >=20 > These lru_add_drain() calls are the sorts of things we've added as > bugfixes when things go weird in unexpected situations.=C2=A0 So the need > for them can be obscure. >=20 > I'd be more comfortable if we'd gone through them all, hunted down > the > commits which added them, learned why these calls were added then > explained why that reasoning is no longer valid. >=20 >=20 > A lot of the ones you're removing precede a tlb_gather_mmu() > operation. > I wonder why we have (or had) that pattern? >=20 It goes all the way back to before we were using git. In those days, computers had fewer CPUs, and much less memory. Maybe 2-4 CPUs and 64-256 MB of memory? That means the value of freeing pages from lru_add_drain in more places is larger, and the chance of the local CPU holding relevant pages in its pagevecs would have been larger, too. On a system with 16 CPUs and 64GB of memory, the cost of flushing the pagevecs more frequently is higher, while the chance of encountering the right pages, and the memory benefit are both lower. I did not find any changeset in git history where we had an existing tlb_gather_mmu, and an lru_add_drain was added in front of it. I did find some other things in 18 years of "git log -S lru_add_drain", though :) I found one place in git history where lru_add_drain and tlb_gather_mmu are added together, like: f5cc4eef9987 ("VM: make zap_page_range() callers that act on a single VMA use separate helper") I also found some changesets where unnecessary=C2=A0 lru_add_drain calls are removed: 67e4eb076840 ("mm: thp: don't need to drain lru cache when splitting and mlocking THP") 72b03fcd5d51 ("mm: mlock: remove lru_add_drain_all()") 586a32ac1d33 ("mm: munlock: remove unnecessary call to lru_add_drain()") Since 2006, most of the places that add lruvec flushing seem to have added calls to lru_add_drain_all, for example: 7d8faaf15545 ("mm/madvise: introduce MADV_COLLAPSE sync hugepage collapse") a980df33e935 ("khugepaged: drain all LRU caches before scanning pages") 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region") --=20 All Rights Reversed.