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 96388C3DA6E for ; Sun, 24 Dec 2023 03:01:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 772BF6B0071; Sat, 23 Dec 2023 22:01:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FB836B0072; Sat, 23 Dec 2023 22:01:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59BD56B0074; Sat, 23 Dec 2023 22:01:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 475DA6B0071 for ; Sat, 23 Dec 2023 22:01:19 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0EC8FA0273 for ; Sun, 24 Dec 2023 03:01:19 +0000 (UTC) X-FDA: 81600210678.17.287D297 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf10.hostedemail.com (Postfix) with ESMTP id 4D9C9C000D for ; Sun, 24 Dec 2023 03:01:17 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xDhAZSfP; spf=pass (imf10.hostedemail.com: domain of rientjes@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703386877; a=rsa-sha256; cv=none; b=UP2hjv3Iik4eo8Enu41pP6DW1ui/Kv5SIqT2m4E2P/vvKZNcVYE31Y2uvVFWRuq/ahD2ps qQQaZHePD+yotLSMbZUUbgNLLcneKVHhqdn4JtzPOc9tltJWM6oO4+2mBQoGf11TpSE13U tMnOhh2R/1dO2XY7iW6mnjMDB/Q/0ZE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=xDhAZSfP; spf=pass (imf10.hostedemail.com: domain of rientjes@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703386877; 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=+F/gcQTO8i2i7S6SvYXe9DNREVuwkHj8qUrFkzAp/gM=; b=WpiOpcFqGxH9Z+m6c+oluP8dPSdkhGcnqYMO3KA0cq+NwBimePyw4mDmkTBNr0SOKQcQ/b dBn7js6hnq1+DVjO1Z7AIqpYIuU4pWmBmoM2sCUNqh2VopIFIqElomLwuzubWWu9nW+7PQ LZFWgmQwoW2M6M7uDIItIebKOJnE76Q= Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1d3ea8d0f9dso229175ad.1 for ; Sat, 23 Dec 2023 19:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703386876; x=1703991676; 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=+F/gcQTO8i2i7S6SvYXe9DNREVuwkHj8qUrFkzAp/gM=; b=xDhAZSfPnflPwL81nY+048Nmu/PFQGYZssJaToA9HLD3+rv6woTsBoKROZdzbwbM8A G0T/az95GX9Oagstx4BMdpsoc6B2by1cU+wqODKNS8CI6zMbp/gXcnE6G+36BQ+AQNsn pYwe9UeMTs2mPeckVHmMABH7uyuV5L2NNF30v0ykanX0iiYtLVPTBNQnAC0nX26F9FHY oyyKtXp2ZT/QkvFxu/7N1f90tbkKQPxpRWXghD0OmGvJ89NGzK2KO5daRhO21FYJGaUK hkZjGeqT3YrNcagtbPCsYO0esd/wnIoIoW7OS7zpo4w0oW2f+FH9aHyXSo4Wsx3wo0bk v8Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703386876; x=1703991676; 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=+F/gcQTO8i2i7S6SvYXe9DNREVuwkHj8qUrFkzAp/gM=; b=CBKHkj97sL9GI2mqPikkEXYCJ8kTmSSI2ISYfwRlYGS1zqBLf251HFkIib2DYc6Aem LDKPXRqmnelP+QCsz9n8KdTYvmVV9oEg7MPTH9Nc2qWnDk0747S5QWbQenuwkA7miGkY NK6OIJqsxcehgUXQL4orvkAK3tKqZdjMjqvYBJCMY0N43xs7vZJw5Pd3542aijkSph7f BDzJYDPPLWvnTKHckb7PKTw/wHGTML2SjgATRpiX+PUWSD1gnhO0yZ3cbwg8Kl3Sg/iX HjF8L2nqPfWbph7bAiIf6WruU+zEdMrMLKFwOkx6cpHBVeZd8wLM9b5168hU5LA0HOFf pbMA== X-Gm-Message-State: AOJu0Yy4l0iNcTLR1167OZ8gElKIQ2y4mQGZs0lw3EXe9JtTE7AMOYiP ZmF7u8a0fLyGwuIga+W8Zb1JRqTy4m6z X-Google-Smtp-Source: AGHT+IFQZRwyjdadHfaO6XJLQwvgeaTJ9wxak9JiLpGUOKT4elJG7t1jjZrEBz0aO3Av7+dtK8DOGw== X-Received: by 2002:a17:902:d584:b0:1d0:9fc7:6bdb with SMTP id k4-20020a170902d58400b001d09fc76bdbmr263654plh.0.1703386875783; Sat, 23 Dec 2023 19:01:15 -0800 (PST) Received: from [2620:0:1008:15:ed14:1d0f:e856:8a58] ([2620:0:1008:15:ed14:1d0f:e856:8a58]) by smtp.gmail.com with ESMTPSA id gx10-20020a056a001e0a00b006d9a6a9992dsm1576151pfb.123.2023.12.23.19.01.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Dec 2023 19:01:15 -0800 (PST) Date: Sat, 23 Dec 2023 19:01:14 -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: <0a052cb1-a5c5-4bee-5bd5-fd5569765012@google.com> References: <20231221-async-free-v1-1-94b277992cb0@kernel.org> <20231222115208.ab4d2aeacdafa4158b14e532@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4D9C9C000D X-Stat-Signature: ox1yw81b3xrg58b4cyetsjykahx9frcc X-Rspam-User: X-HE-Tag: 1703386877-695872 X-HE-Meta: U2FsdGVkX1/rKRR0ixKmc7oIjAAd9eoUBuGxszJIHOLYWrd7W/j99q22+9I6f9gVmmBMG3LJCOVKR5WIY9ZfrXK0uc16ES9MAaJ06GFMTgeZoDQUwwwB/ppNy7gwxmfT62ilYV9Ey9Hsr+mmFydMq7rDdFD3kr6pIuQ0nVM9uzfbg/X9mupF61AXIA8aucjruFCGpe+tUXvVepEdF1ngWHmEN9Yt39ENibWQZ5EUvEU2z2FGfFFcTeWC3D30qJa8wTI+Cb/4tbAhBAfL9zq7pXrHkBy6wF30GtfIDBjHlnW9zhvYFUZgZgGd8GULcibrFpZxFGRYicTrgJ++opUxGX/DRKlxk+I4jXuqIypGEmWdbLLaav938ciGd6Xb4KATgZDuKDze1QzuF7t4qEG3z7dhJfEu9W+w1F3FFrrmLmWACGKUfz1DPz91IlzPhd7nk3Nbj4yY1QA+njNxrB8DbvBlWguoHSAsmE0HkkkaXhkc7Rn4Qcv4QDqjBSZ0b8qHge59lduN9UUGQBOukzpmaYociIkIFHfpKdgRshZDjFhCB5yw/JfAgxQrVPKLx+jSomrZ9ZxTUY7kPbfpnPaA2JyTOBcEMrD0gN1JYeJY6XF1qmmtaCyLcoNE8HbSi5uj8oaAagsue/WRr27DxRrKq8WN+aDUsCVhQWEBxDaEVmR/Zuz9kyr4ZaPHGvcijzClkOVpdJmWKcO0UH6alLhrydvfutauqWpfD8+Z0ZlpLDFeoWYNJS6CL4GwM5Qd5p+lTEt+ppz6m99TzsvOHtHsGtLBXT+gigCPmIR5RnTGWDjCRTXWqm6mN4Iyh6MQ9qhfrIYkg4vb8neTING/x52uEVuuho91Qv2kcg7BLRBNNKR6Qfw/TPjQ72qZjoFwEY4BbAbvplBPbt76zI/nMndD2iVtx6gWoqZ/EdYpDxBKxubjyCoqTU5vZl2Ub2oVF/szEMbwzay+3GFygCMdWWF 6zFVmvbd JkJhci+XNOAEy+mgGiZigiDjim5CxGcTjzJhN54PZexjdnJploW7ffLnYQp7U5paMgmnKgVL5UL7veRoN8ZNRD2KwjQC4ePtTJ7qXXKq4LxeYO27FnhCwgrPWWr1gtA7dJ2W6TyHPslJyUFU/7dVAxpIAR1ziIxSbmA9ABYNneOtzN/FMm3c95aWkkgtgBCAiRt/qft8jv4FSDmWpB8QbdK26Tqc8z8HxRhDZV8U1FD6mPieq6O8dDsRH+r/3wC9Pk/pYdm446O7Qnlc13mkZU7luMd+6vax8vRw1JV01Nnq25FHpwe7rV4v8GuWl1xPvLLUsYsBNRgEjtJuKSdShihdV8d5K/QWt7cOe8+xcn5njXMA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000482, 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 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 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? > Where the swap slot cache itself delays the freeing > of the entries for an arbitrary amount of time. It is not freed until > the cache is full of 64 entries. This delay can be seconds or even > minutes. Adding a few microseconds of extra delay to existing seconds > delay really makes no difference from the swap pressure point of view. > > Chris >