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 2DC9CC46CD2 for ; Sun, 24 Dec 2023 22:21:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5359F8E0008; Sun, 24 Dec 2023 17:21:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E5E18E0003; Sun, 24 Dec 2023 17:21:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 388088E0008; Sun, 24 Dec 2023 17:21:00 -0500 (EST) 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 245EF8E0003 for ; Sun, 24 Dec 2023 17:21:00 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4E82B1401BA for ; Sun, 24 Dec 2023 22:20:59 +0000 (UTC) X-FDA: 81603133038.20.08503CB Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf24.hostedemail.com (Postfix) with ESMTP id 89CAF180006 for ; Sun, 24 Dec 2023 22:20:57 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AmWttmbm; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of rientjes@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=rientjes@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703456457; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7LD140+Xgkenp9ciiR1m/6SC0DrA959WMgfk0mFXyRk=; b=RVI/tmwNt7BWwzfhV4a7C4wI3zVnXhunemnUTQVu/XQ7o+J4OYAUT/Bn14kkXUiKNhiSIT 93k1I4bDwG+y5lg7UW0ExyV7jmYoU9xucQHya15VZHLyDy2YAkjLCv46Ftf1eHEw+tLz4r JUp+pgN/dJqQ9UObQuunmy4YoalyKms= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AmWttmbm; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of rientjes@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=rientjes@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703456457; a=rsa-sha256; cv=none; b=EXzWZh74BJVAA7p81a4veWSEam5SZVADEUzmFgJAKxpumhAJWL8bGKC4aXcuj2iFcTcptj 3nsFKF2zZnNSJburYJHnYcIgm+/dfsi2eu0xKEo0oAwxGScni6do4GnS0trR7Q54eEu9EJ fnkx4ym5bXSlA5c3JjOHbtK3iGGftgs= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1d3ea8d0f9dso260995ad.1 for ; Sun, 24 Dec 2023 14:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703456456; x=1704061256; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=7LD140+Xgkenp9ciiR1m/6SC0DrA959WMgfk0mFXyRk=; b=AmWttmbmDeANjSKMSsTyZXTbpqOVjeG57IZymdO8TVNfKBJQvuPPL5y2EgTSG9YqqZ 1YYEgYOQvBY1tU9D2jVWcvvmeqGWVdTkvo1SoWrs6am0Uork7+MLS6BxhmgEM05q6TK3 oe6k2HeGwa0+7SzcHLWNefA5o2HdIdyk6OyXQ53K2AYHnTidst5sCuA0ymuyaVgNv7Te tJX6i5sV6k/GDz0N2G3q3N5cRINM2xhlUhfWHMgj3wTyMcA/9GjXSlW7xGoz8YFLbgy5 9G7VRKxbKl0PyzFvVomo1Ii7uN/o20vacAYHMomaTrDWZ32l35lDzDpXk/6k1EXWqeLc EqTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703456456; x=1704061256; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7LD140+Xgkenp9ciiR1m/6SC0DrA959WMgfk0mFXyRk=; b=YWjb3xIitXvrmXOqKqZfy8w8mbBUOPZTgReae+xXqspTDoRICC0EQzYwcEWPai6zE7 hxP8372OWlcqnMEKCfbozdXjk9Le4ywS9+3F9cHdqheto3UXbttAf6V8Yof0CSQCpp+k 5KXFzToCq1iIYp5Lt0aOyzNEPo5mhSGCp2M908RDTQaj9S11C5EVGkg0vTYUXnM18G+t qY7qOcYWF9isdZvCWFCG8QxkwJlcA0yCGKKC1gCiS18IUf9M4k9rbT8rAnsLtg+a6fQ3 LuoJBfXzhyaYEOairzVSCYd466l6IqGBs6pyS7nu3BD7I7goHbaR+P3ASLZyHK3DROny k8lg== X-Gm-Message-State: AOJu0YzF+iBjNxB3D5xvmZD5w2f8N/0cjipmAfZJumtYZnkF5n9ArDpj LV7WUWOhsOCFKnoam7k0HLYgv736QJQo X-Google-Smtp-Source: AGHT+IHDCDsQKo8TkgmKnfoJ90RsBFmNqQ8nt9FOQZmtwXMiUyrVc0Z600567/ZOEgcDu3sinHqLdg== X-Received: by 2002:a17:903:41cd:b0:1d4:f4:bd18 with SMTP id u13-20020a17090341cd00b001d400f4bd18mr302116ple.20.1703456456102; Sun, 24 Dec 2023 14:20:56 -0800 (PST) Received: from [2620:0:1008:15:c723:e11e:854b:ac88] ([2620:0:1008:15:c723:e11e:854b:ac88]) by smtp.gmail.com with ESMTPSA id m10-20020a170902db0a00b001d0b4693539sm6947242plx.189.2023.12.24.14.20.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Dec 2023 14:20:55 -0800 (PST) Date: Sun, 24 Dec 2023 14:20:54 -0800 (PST) From: David Rientjes To: Chris Li 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 Subject: Re: [PATCH] mm: swap: async free swap slot cache entries In-Reply-To: Message-ID: <7454d4e3-a2dd-0571-5ac1-99e99dabcaf0@google.com> References: <20231221-async-free-v1-1-94b277992cb0@kernel.org> <20231222115208.ab4d2aeacdafa4158b14e532@linux-foundation.org> <0a052cb1-a5c5-4bee-5bd5-fd5569765012@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 89CAF180006 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: qo3zct5tctruzsbr6ip865a6sbk1pihf X-HE-Tag: 1703456457-423069 X-HE-Meta: U2FsdGVkX1/kfC4/XVYLnQ0QqezLWAiHnCCaMjvZR6YREXhfhQebYDCH6plXEccVS/fPJUNAhP3aEiAawSX/JmYBdoL6eAdibgt4faNH9oebLlBZ3H07gFKe1zVFyGUUMHcXy66U+0B7/cSacymGFu4tQshTWwDmXXgX2dptnYj5IkJZZvl/T6rk8L2bGL8oqgqKS7d5kPi6ZBGd7Kt3nGSPMcmuH3EQAuc68yGCczb25kG1TkHuksu1W3vSZPePkysnUk+inj8tcWt3FXJ4N1um2THM5ROrGrBqbgdMqz8zbV8T9+fMVoPpjcBySHlC5hPzzLRY3wkPzTQL9hzh+pjK195kTbnrwZjzxWHJsraNMWfEHJIaceRUs22OB5ZyDrv2+W3WxmDKE+Ja2zRrwb5l/HGVOJzvsbsgBZsrwM1Y4RdhfPlVshTTwfM5aY9h9reuAIEVG/HX3FvgDQwj48/QcPZew4JKL506FMY3YR0IneLTsPcvEyYYtsPBUb6A+K/OJcF/bS0ODL8XRz5pUuPtei/R61/ABtNlI+RyzU7z7tg5+Lg7p/cmjg12d5mT+ZBQ49f5gqtKI/4hQEYHtQfxiKYiSWKMdJpgKgwQqMGjLy805d3WGAo6atUNlz/OSX2Ak+DHspcIPU6XTEptrZfibZiuZo2O0xRpDXwb314EgY/ggsrc6Vtp0xRUUfhmmOjTJ6LBTqFESFP1lU39S6Azq8ULqXg3rip4H1ZB07xMJFHXiy7iwqUbwkBdi1AZzpE0i+OL5JqsPEitcVvbnj+3vdh+0M9cNFm+8KC3Myhxfmr9Xwts/fmPx+tYrpAaRD827p6MrHCqFfII096wA9mqE8sTDKaYjk42IXZTPHkoeB3iZEL/zzRi/79mAeqSoojqwiK0Z+5/kPUwGcCARqkT6FR7+Uo3AgSmsTFAt+ZkBz/UGJwdBMQGNnPCSAlCHszQdDNRVwu/QhFquSx dqymVp6M TrgxpD+VuHAIU6TJr8bYs4RA4P9KYvgXUEz5g2ZD7ajPS2M4ZsCSIlgR/o8dZgYbUvXW/fYRguQtwjxVVsp+1TgRJp+61gYDK4j9SrBbpeY8UJl7GrIcc7UmRtN1SiV6zJjb8BlSg8ASqH0mzzKq/08QK8Oi9fqAVnWaTEj4zZkWS3GGIgHQYER8Cjcqq8SicrJ/ZSDeT+sWJX4S2z07K81aXRoYD2eSrYlXCL3Nu9KZhgo0ZlNb5G3NO79CicR3akBOoy22RkX0EEUdkbxGs7PRy84j0pSQ67u/tc7ZPpJ4AdT37tFOR4D8IsB9T+7zJ2svIrUIC4Qe4pjgmuYf9Uy3tJgtHzz11HWmDM7wdGtF4Wi4Gl0E7WvOx5860tPxt+isSHWfcLZseB5dCY+Mli4dRmQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000050, 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, 24 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 the > > > > > > possibility that we stay under memory pressure for longer? (Assuming 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 pressure > > > > > 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 microseconds? > > > > > > 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. > I'm simply trying to compare the pros and cons of the approach. As pointed out previously by Andrew, this approach actually results in *more* work to do freeing. Then, we could have a significant time delay before the freeing is actually done, in addition to the code complexity. And nothing safeguards us from an exponentially increasing amount of freeing that will be done sometime in the future. The current implementation provides strong guarantees that you will do batched freeing that will not accumulate beyond a pre-defined threshold which is proven to work well in practice. My only question was about how we can quantify the impact of the delayed free. We've come to the conclusion that it hasn't been quantified and there is no guarantees on when it will be freed. I'll leave it to those more invested in this path in the page fault handler to provide feedback. Thanks!