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 BFEBCE77184 for ; Thu, 19 Dec 2024 14:11:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23CB66B0082; Thu, 19 Dec 2024 09:11:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EC4E6B0083; Thu, 19 Dec 2024 09:11:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DBB36B0085; Thu, 19 Dec 2024 09:11:57 -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 E59B56B0082 for ; Thu, 19 Dec 2024 09:11:56 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6F07C121672 for ; Thu, 19 Dec 2024 14:11:56 +0000 (UTC) X-FDA: 82911895836.01.4FAEE7D Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf01.hostedemail.com (Postfix) with ESMTP id 7FC1C4001A for ; Thu, 19 Dec 2024 14:11:29 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734617492; 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=Npn/MjnabCP9LdKDcpw2hRGJBe1Limk9++zBASSYLNA=; b=iFjjcNV1YmTLhK/ITCQhhu3iuqPlELeXpOU7hxfzRH3/k0AHt8dStsQjWLVhFNjtQwa3r7 QCMLqRzKK3plua+zeNE/VH4qICAqwU8JBL9FSfoBBXONpLJwB9pwJaVrziX3U2FFpphkVA G2ZgQ2U7FdP3o8XdrOLF4/v/Ekh4xG8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734617492; a=rsa-sha256; cv=none; b=aifUJkS19wj4XbAEI8/bdvmT+/P0xc+y1/BylGs1wtehfwHJIXGdiy4KV1zifJ8vvkt3bT iK6Clv3tVwvAznZSxrIj0OdhtLE9JzPpFkMJZAWlxR25bG3BBOu/bUd0yqI43WVgxIqaMc W6eHY9amiWtNuusmtQZ0rRb7PECZJnU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of riel@shelob.surriel.com designates 96.67.55.147 as permitted sender) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none 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 1tOHF5-000000005rJ-33Ql; Thu, 19 Dec 2024 09:11:07 -0500 Message-ID: <58d69446edb0e2b3b4edec442043cd0a9748f15f.camel@surriel.com> Subject: Re: [PATCH] mm: add maybe_lru_add_drain() that only drains when threshold is exceeded From: Rik van Riel To: David Hildenbrand , Andrew Morton Cc: Chris Li , Ryan Roberts , "Matthew Wilcox (Oracle)" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com Date: Thu, 19 Dec 2024 09:11:07 -0500 In-Reply-To: <189f4767-e7c2-4522-b943-b644126bf897@redhat.com> References: <20241218115604.7e56bedb@fangorn> <189f4767-e7c2-4522-b943-b644126bf897@redhat.com> 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-Server: rspam02 X-Rspamd-Queue-Id: 7FC1C4001A X-Stat-Signature: gtmrjcmu11x367ot8a6u3c9gmysez1fm X-Rspam-User: X-HE-Tag: 1734617489-835114 X-HE-Meta: U2FsdGVkX18Tc5hUGeqzrPjZc4npofMbeB6Bk6NZUJBmHda7rEZ2vqWXS4bCyMDI4znAC7ZiOdY65WTu5GL5XpdEd+/QKowSj0gRdps8ykxTnzsjhz1i/pMjERlKyrXWtb4jsdLe8ogJGNm1Eu3PmH+fwPm8EI9k5Br49S0rbnCjfTBnYz8VDTBZzuq708kYPUbyzride6x3UFUXXoczsCJglg0xHCb0BOLY7htxwwVIxgbdQY/u1zW2dL3EnAdWjcUvkXqi4IA1PnDUQDkW+qVvaDtsbKHlC5z1xyVEiHjM9rBcjDZzlYfCfnC9K3Mv7BpHyj7Q7LHjm4g+/KGgQvlBSJJP2zY/iq2G+UmejVbsooQQ2vXWfuO2wr8/lVJizc/8PTGIbnPFHLjJZq0H/7tlNJ/uPGWKKa2wPQqjBjbOAipaQZThOhcdBce0XlmJlsEYg3Fc+YB6RPa2QKUHL1P/JaMkXU/foErq0ygV7UBmjlM/8gyOypbDlXbYVUwMbfgUpZY11JR6gB488Ir8WN4iIV9yRXEIK0IqxA/iwRuPWCeI7fZ+aDWezcmWqevxUfIgTC+k+o4O5PpOcE635OKdaNXZ7Z0NWFe1OqvJnGIOSglgMcX/0VwnV66XPY4wr3YQzYbQIo1S46AjURzIBvHAKZLKZ2NjjtdLZDeFJl/qNQRtFrb+fmCtunR853yWvcoG1mJmbanP9BLRJMD4G1P4achr/eamft0EOs+w24tf4xfeFyc03AFjktCu6FHAuGgRQB7TeE1cboIWzjcFesTT+ZlPzg63jlRLF304Y8EbjU0CVThJn/yYePNv8ZV1eM2u/bKHzbFt1d4jbBckkJzpwNTROyi7Aku/xgjy+XQHHfOPQOAb8W3Q9gtZbAPfY9HgejdEl7lpG7QOVNAdPDbC8dKrSpK4Bgbrrp1Car7oss5erY6syUfKDqjAPdvMZY0cqIcNDrDolfl9QBu IrAPBLHU Rzi0CQh1bbxQT1+EblHnoyIyitRmMf+0iT9g3y9FZdYsPD1Ua2GNk+1XKOy2NroEmKU9r76I03lEJ5Lllm6oicV9mIY2WzYtXlzW/YxXSgwz4GSZ6qVUqdt/eCcU/IfbgcuPRuX67xWjoZjH/ND2JP6vw/G/FwGak70dKbaugaZsAGr+0dY1Pk40Smp7DMd059QM77qOPQy64cWR3QW+B3RqTo3d7OMFPm2q0tUw+w9dHfhEabJIb9JciEWi3fODsvHjV87Kru2B2qrUmezkLxyBMkg/ZiG04cIg13XfcepkSwfARJINcDX/Row== 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:47 +0100, David Hildenbrand wrote: >=20 > > +++ b/mm/swap_state.c > > @@ -317,7 +317,7 @@ void free_pages_and_swap_cache(struct > > encoded_page **pages, int nr) > > =C2=A0=C2=A0 struct folio_batch folios; > > =C2=A0=C2=A0 unsigned int refs[PAGEVEC_SIZE]; > > =C2=A0=20 > > - lru_add_drain(); > > + maybe_lru_add_drain(); >=20 > I'm wondering about the reason+effect of this existing call. >=20 > Seems to date back to the beginning of git. >=20 > Likely it doesn't make sense to have effectively-free pages in the=20 > LRU+mlock cache. But then, this only considers the local CPU > LRU/mlock=20 > caches ... hmmm >=20 > So .... do we need this at all? :) >=20 That is a very good question. I think we need to free those pending pages at some point. They can't accumulate there forever. However, I am not sure where those points should be.=20 I can think of a few considerations: 1) We should consider approximate LRU ordering, and move pages onto the LRU every once in a while. 2) When we are trying to free memory, we should maybe ensure not too many pages are in these temporary buffers? 3) For lock batching reasons, we do not want to drain these buffers too frequently. My patch takes a small step in the direction of more batching, but maybe we can take a larger one? --=20 All Rights Reversed.