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 2812DC46CD2 for ; Sun, 24 Dec 2023 22:07:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A35896B0083; Sun, 24 Dec 2023 17:07:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E62D6B0087; Sun, 24 Dec 2023 17:07:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8ACF56B0088; Sun, 24 Dec 2023 17:07:08 -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 7816F6B0083 for ; Sun, 24 Dec 2023 17:07:08 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 514C6A0282 for ; Sun, 24 Dec 2023 22:07:08 +0000 (UTC) X-FDA: 81603098136.17.A2838DE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf06.hostedemail.com (Postfix) with ESMTP id 672C118000E for ; Sun, 24 Dec 2023 22:07:05 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Jsf/SXha"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703455625; 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=9yEUn4nULJf/G564+8bYWk6YAOIAJAsAq0AwThjIQWU=; b=hnAA+tO01HA/xme2Dm83XEo9C7w/DeCkOUCxVcvG1OSTUZQXEvz939KK4vdaOQkwbO8X5p autaZ1C926/J/oSFaneWINklRRfXlbDGnkhfMc6qF2pn2dREDx/NA/U4gvNX4PCZ2hgOFe 3UJw4hQ9WeSV/GvKtdm5VuDxJ9LboKE= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Jsf/SXha"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703455625; a=rsa-sha256; cv=none; b=IcVWVZHP7U4eInOLxddyv1gAKwyEGeptbHFelJ3/h8uYrTI+bomofpFx76cIT06beqnQbV zwYlNmm/v5i1OWFUS5G83t2VrSZKsNyVzWo3EonkmEF5SV8zJwrK7Rm+2gSnjXEr2JnpZT yJqpsSjGaJ2R4lVkM7Swe+Oam8JGjBo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6F13360C23 for ; Sun, 24 Dec 2023 22:07:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3864DC433B7 for ; Sun, 24 Dec 2023 22:07:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703455623; bh=Nk2FrYMqgaYmbhuSwjleZKW0X7pw9egeGLSDxiFxB0E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Jsf/SXha3n86BTW3jvu6ruXABlJQEQhPdbsv8I5uNAWmJ76hED/bWLasw3z0mRUDH Q8RuHtPbrfAkCQoqHN4cjdU91A2wdc/48vjPs2XSDEPYx9KQikRVti4Xihe7jyZbSY mTGwUGhMpm8cqdm0GnvGlzuW3yesibQgQQgsl3mOW506GzrxYEBxqlGlLDth1yFCZh RnYgtDtJxNcRWAscyJc6Tmt/6a62RMYJ44g6k25+i0ZXjpvIrOXsjXoeVnxPVk8GJs 3x22OjXx/xNw3qiLMY3BBYVS14THXzC/a7yQw2LLwEmr9/TIXpVCUU/U9O/US8XHN1 +5PqGs15oOH+Q== Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-6d9bd63ec7fso24216b3a.2 for ; Sun, 24 Dec 2023 14:07:03 -0800 (PST) X-Gm-Message-State: AOJu0YwmJrzb4Feqh+gYqlrOsisa/hMZGEXvT6LHGB/H051XGjoc7NAW XysDYR/ydyMvPWPLn9JrZQK1H3v9eFaWkJEMvaU6t24YleuH X-Google-Smtp-Source: AGHT+IGw5KTuIs+jEjEsKIXIQ428uRz6x09URbQZ4va5bdbBI9yGc9Cn7ASlSAcocbh1ql7JUcj/ofJtQLXcyLAyEU0= X-Received: by 2002:a05:6a00:1acf:b0:6d9:a865:7fb7 with SMTP id f15-20020a056a001acf00b006d9a8657fb7mr710403pfv.13.1703455622282; Sun, 24 Dec 2023 14:07:02 -0800 (PST) MIME-Version: 1.0 References: <20231221-async-free-v1-1-94b277992cb0@kernel.org> <20231222115208.ab4d2aeacdafa4158b14e532@linux-foundation.org> <0a052cb1-a5c5-4bee-5bd5-fd5569765012@google.com> In-Reply-To: From: Chris Li Date: Sun, 24 Dec 2023 14:06:50 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: swap: async free swap slot cache entries To: David Rientjes Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Wei Xu , Yu Zhao , Greg Thelen , Chun-Tse Shao , Suren Baghdasaryan , Yosry Ahmed , Brain Geffon , Minchan Kim , Michal Hocko , Mel Gorman , Huang Ying , Nhat Pham , Johannes Weiner , Kairui Song , Zhongkun He , Kemeng Shi , Barry Song , Hugh Dickins Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 672C118000E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ia3ipy4qyqchssx61jzqwc35fxkhu9xu X-HE-Tag: 1703455625-106899 X-HE-Meta: U2FsdGVkX1+bPp/xDUPt4fzUlpq+9sjZ2bvMORdb18HIgYyecA/FcZ3HR21JsqPN8ISkquGKETTPArDe18dmUv2PeOArugMc1Z4ItPr4SEyi4/YlAg4OEBS0Xn9YR8w8qPuao2hm3GIQ6YxTKuvhw0zWLEh5TgTkV899Y13sErvvg1T8FZTELKEjmu3mag1Q16ByDAAigqQFJEUNWplUPhI/W+jrGNiV9+ELaS6wylw4RYDt8sH/0eP4qvXfXGesiQYvd4FoNI8WQtWD4g62Mx/mvhJhceiJMPSVd7S8dfpPFYsCg1tCr9iyY8ZHtPbackS1MN5I1HZyACqNcJv5nOv3bilR1NunJef1D4F/R8BrlyfP0A/F2l4hqxiRTf6GOi7ZV/plaAWJFW1kmavqh5mC7hxkVGuVy9+OKio3lhKg1pqE2QHVa9UMF0DuM8ZNXLafDtfdDBpkoC7nZhickrfI/Ay1eExvaBk2MumqdVYuSoBloDJbudnnky3t2aXkcAQP/88sdLxflpX5zY0h6BUGOJgy+GaqrpaSzo4fbxku9sLmx1Slbsk85vTwxfIKQDRwC2srLlYHC2bzsBID/tQnm9T9hebaTNW0513HgOdc91yABwnTOU4Yzrpfn7DfGbA3yq32xQs7WHR1cYgmNKd2C6Cx5fpD8lQN3Niwdw3wjU+C93QjLpWgNCiRbaFhr8cZvrC4uLq76LwP+OH9MnLM52gBaMWYBSUUAU++4T9gwXo9w5liwfBG800/EPTaxRUI/+YcNQP1jZ9q5jWtkrTkSoeS5orh4c5QwmVrFvCvqrtBugBEzngRM40kPoepSJlxag9d+h3nNWT+3qAodugU6uRFoxQFEAXKRoOeU85Nu6MPzsdn6uOhdVMOzcgRWZBq3b6EeaFQJU4i6gPGQ092C2FS8Nt/93/RGzrN/94wHBtdxMfa2ndKDu0XND9YFQBWjiyPj69AxdvBGg+ fw7rm3hF UBNI/1MEaLZE8wscEogj342Zj5mnyL45weKOfxtQDTCFg/suUe/qb7UW57v6vjgEr0NLBtKbvvpZUIA02lmxYu2UvddupL+B6AvzZ6YHZNy5D65nxvI1TiSO7ntDdOzuHblhu9QDcGP9kXo/fav5Aq845zjqO6e6Jav2EfWnbPuWkRD2kRkRsOQjvnDgB/n+sRGUhdfnCOJmTrgISjbc9y2r5wbcP6Z7bDRTmqreVv+JeYC2dkvO2vWLsqg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Sun, Dec 24, 2023 at 1:13=E2=80=AFPM David Rientjes wrote: > > On Sun, 24 Dec 2023, Chris Li wrote: > > > On Sat, Dec 23, 2023 at 7:01=E2=80=AFPM David Rientjes wrote: > > > > > > On Sat, 23 Dec 2023, Chris Li wrote: > > > > > > > > How do you quantify the impact of the delayed swap_entry_free()? > > > > > > > > > > Since the free and memcg uncharge are now delayed, is there not t= he > > > > > possibility that we stay under memory pressure for longer? (Assu= ming at > > > > > least some users are swapping because of memory pressure.) > > > > > > > > > > I would assume that since the free and uncharge itself is delayed= that in > > > > > the pathological case we'd actually be swapping *more* until the = async > > > > > worker can run. > > > > > > > > Thanks for raising this interesting question. > > > > > > > > First of all, the swap_entry_free() does not impact "memory.current= ". > > > > It reduces "memory.swap.current". Technically it is the swap pressu= re > > > > not memory pressure that suffers the extra delay. > > > > > > > > Secondly, we are talking about delaying up to 64 swap entries for a > > > > few microseconds. > > > > > > What guarantees that the async freeing happens within a few microseco= nds? > > > > Linux kernel typically doesn't provide RT scheduling guarantees. You > > can change microseconds to milliseconds, my following reasoning still > > holds. > > > > What guarantees that the async freeing happens even within 10s? Your > responses are implying that there is some deadline by which this freeing > absolutely must happen (us or ms), but I don't know of any strong > guarantees. I think we are in agreement there, there are no such strong guarantees in linux scheduling. However, when there are free CPU resources, the job will get scheduled to execute in a reasonable table time frame. If it does not, I consider that a bug if the CPU has idle resources and the pending jobs are not able to run for a long time. The existing code doesn't have such a guarantee either, see my point follows. I don't know why you want to ask for such a guarantee. > If there are no absolute guarantees about when the freeing may now occur, > I'm asking how the impact of the delayed swap_entry_free() can be > quantified. Presumably each application has their own SLO metrics for monitoring their application behavior. I am happy to take a look if any app has new SLO violations caused by this change. If you have one metric in mind, please name it so we can look at it together. During my current experiment and the chromebook benchmark, I haven't noticed such ill effects show up in the other metrics drops in a statistically significant manner. That is not the same as saying such drops don't exist at all. Just I haven't noticed or the SLO watching system hasn't caught it. > The benefit to the current implementation is that there *are* strong > guarantees about when the freeing will occur and cannot grow exponentiall= y > before the async worker can do the freeing. I don't understand your point. Please help me. In the current code, for the previous swapin fault that releases the swap slots into the swap slot caches. Let's say the swap slot remains in the cache for X seconds until Nth (N < 64) swapin page fault later, the cache is full and finally all 64 swap slot caches are free. Are you suggesting there is some kind of guarantee X is less than some fixed bound seconds? What is that bound then? 10 second? 1 minutes? BTW, there will be no exponential growth, that is guaranteed. Until the 64 entries cache were freed. The swapin code will take the direct free path for the current swap slot in hand. The direct free path existed before my change. Chris