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 CCAB7C4828F for ; Fri, 9 Feb 2024 17:52:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 261426B007E; Fri, 9 Feb 2024 12:52:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EA876B0080; Fri, 9 Feb 2024 12:52:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08B856B0081; Fri, 9 Feb 2024 12:52:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EA9346B007E for ; Fri, 9 Feb 2024 12:52:49 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A7A0840769 for ; Fri, 9 Feb 2024 17:52:49 +0000 (UTC) X-FDA: 81773010858.16.8BA93C7 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by imf11.hostedemail.com (Postfix) with ESMTP id F249840013 for ; Fri, 9 Feb 2024 17:52:46 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AdLIwSGw; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 192.198.163.13) smtp.mailfrom=tim.c.chen@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707501167; 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=a/fUw6fMo45Yrs0O/0hz43/xzp7ibvfIcU/uzpFiupE=; b=tVJYs552mDlSq2pzfEuIwuAuQYmShm9D0KJ5v/tJL7YVfzhTlrY3b0+Ccfy82vtI6McOh9 A1VjDwHdpQ/nXp3yS9gSCcUXk6ITUSIJa535eM2Dw50CmfozN8hj20rbsYbxTGxjJ02Udc ygo4nH6Nqf6iUG4A98NkAFtn/lIZXp4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AdLIwSGw; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 192.198.163.13) smtp.mailfrom=tim.c.chen@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707501167; a=rsa-sha256; cv=none; b=JiHOUiT9wYTAUCB+/Gnu2xxCpNjZXE5+xdZGGFkJXLSvOY9C+BB/RtYmRRGMc7fd5dc+gL QniUluuZXGJdvFjJR9ZGDcgXY2YPV358r8ob3OIiHba5iSDCSQg3pHC0s43uZWIwISN2O/ RdzQRQEzTDPWUFo/HQbd/Ti9setwrH8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707501167; x=1739037167; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=r9ptD/D9HY0EEOB5q1BgMMq6Q5nu3lZqkdrr6XOXEtM=; b=AdLIwSGw8D/TJqjcUlo7+VRgSwbN7gcQVr10QFJ2GT+m71zYoPoxzMRu n0o37lr1AjTDlJ/xOiDnkYihxIYOes4rb8rVJP8n/8i3cv0q3BUgIiNCQ ug0xrk/OaCOqHlyB7/GwOXpp7kIjJuA2QG8kqPVk7mq288X44UhmP+eTd Gp/yBKf8mFA3I+f9dfSUoZST+oBJ/ZcscZ8QTylX7WJtk69AX3i3MqB4i Cm+q5wC4Z/jDBgwI7MmqxPLVFyM59JJ5J9UUTpcQ8dm0XlTHL+ZjK7y// oD5xztdrQE9K7UQi4JL0IQX1mstbM23FW0OfFDZMAN3MmsNGGziHM60HB A==; X-IronPort-AV: E=McAfee;i="6600,9927,10979"; a="4450970" X-IronPort-AV: E=Sophos;i="6.05,257,1701158400"; d="scan'208";a="4450970" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2024 09:52:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.05,257,1701158400"; d="scan'208";a="6746729" Received: from mfahimal-mobl2.amr.corp.intel.com (HELO [10.212.132.151]) ([10.212.132.151]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2024 09:52:44 -0800 Message-ID: <4f1d0c0369e3b08cb0c8d2271396277df6e1d37e.camel@linux.intel.com> Subject: Re: [PATCH v2] mm: swap: async free swap slot cache entries From: Tim Chen To: Chris Li Cc: "Huang, Ying" , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Wei =?UTF-8?Q?Xu=EF=BF=BC?= , Yu =?UTF-8?Q?Zhao=EF=BF=BC?= , Greg Thelen , Chun-Tse Shao , Suren =?UTF-8?Q?Baghdasaryan=EF=BF=BC?= , Yosry =?UTF-8?Q?Ahmed=EF=BF=BC?= , Brain Geffon , Minchan Kim , Michal Hocko , Mel Gorman , Nhat Pham , Johannes Weiner , Kairui Song , Zhongkun He , Kemeng Shi , Barry Song Date: Fri, 09 Feb 2024 09:52:44 -0800 In-Reply-To: References: <20240131-async-free-v2-1-525f03e07184@kernel.org> <87sf2ceoks.fsf@yhuang6-desk2.ccr.corp.intel.com> <7f19b4d69ff20efe8260a174c7866b4819532b1f.camel@linux.intel.com> <1fa1da19b0b929efec46bd02a6fc358fef1b9c42.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: F249840013 X-Stat-Signature: supimoinu5xkyhb7kxrjkfwd5b54tz3w X-Rspam-User: X-HE-Tag: 1707501166-339321 X-HE-Meta: U2FsdGVkX19fxIaK0AXcKIReW7Lo7xJ9z6A9RMk4MguY16U11iXNXXCLz6eRpEOXFgdst+3fgYXlCm4JA5SE5KMQtsqJCiWHpbhKxiGwBCyyNp2MBI5uYgxrHmlzIJd8u9jLY4JgGsEAu/038nJRYcd4h3jxwN/9OU5rYM29cRDDT9bcmad4luFU9vmcJxIGLYAV5ZfdpgiAGORLzoCtFl/Sk2wKOoS7IK8ZB+p2DXqD5IWImZnpm896Dz0u7NFAgbfYg+MjT5Yni2hdanFfT61GhnN1DsG9tQ5gu30l+DEnqbKZc4OApsJiMQ+hwkB22Qb68fz9+8+ITPRdtlwcaUE09ctRkiv5oCBIP4/mTEYkMgWKXuq6KxPdzzb0PlNnWhbqVVjiKBZAoHbw+UEaGu/pv8ZxPWtckOV/5HiChD9ln8Y+mjpZARtnmk3fBqgvlCXSkqoipAv1rsUIjZIeFn+ycxNBcygrug/+WZi3DIuYCI+RN+RKdQOVjcm74UJxeR4FQqxtw8Xod674tb8cDcQeL255tqHMxy+o2G0iDVUh8M1v4Ew2Igg1jYZdWDSmhvBcV3UtimYBABMPlCUQnTsYoLKE3XljChO4eSBbExCzGIkg1dSbO8A84mNn0VlgjMZZc2RCnLUK0sr6ea/F3cWEby1MHsFwCXjWs359ixAuUcWJBLQ8ErwUZ+pncmg+m/KBEePqMFwRgPFyc7swXFzdneTA/PwESSTLf6AIpLvEF3kytq2/pVCYMvJFkDh/jNkVrDtTsSXJv9/DBbPgYsL6354xV4AbfhHT2WeUtokuepRGf2hHyGMKmz+Rz+CmeEbbmbgrFdofaRLuedSxVFWaatsxkcoI3OpObRmsqiyI+zu4mKPk/Wn5919wv36E42SQoVmNQL5uSX0MpxyfYBafr1mKm5HV2UoExkPLzSfWSWgyDsjK0aevCwz8fgzgxN6+aGvzyIoEeomzRpr 7ekqCEUz tudFgV6VPx+kaU3FCkyZg6Bvqj/eswaYUY8mR0hyxyD1iJkyXkmmbbU3k6Wp5/mtZFnAV1E7qbkJ3Im6UMwAocirseAJJ79AM3J57ZA6X1Zl34sYO1XLKnzEgBZQbfLLYOUVJlK4HZniAxSffw74O9YS9hA== 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 Tue, 2024-02-06 at 17:51 -0800, Chris Li wrote: > On Tue, Feb 6, 2024 at 5:08=E2=80=AFPM Tim Chen wrote: > >=20 > > On Mon, 2024-02-05 at 11:10 -0800, Chris Li wrote: > > >=20 > > >=20 > > > In our system, a really heavy swap load is rare and it means somethin= g > > > is already wrong. At that point the app's SLO is likely at risk, > > > regardless of long tail swap latency. It is already too late to > > > address it at the swap fault end. We need to address the source of th= e > > > problem which is swapping out too much. > > >=20 > > >=20 > >=20 > > Could some usage scenarios put more pressure on swap than your > > usage scenario? Say system with limited RAM and rely on zswap? > >=20 > Of course. In that case what I proposed to do will already doing what > I think is the best of this situation. After grabbing the cache lock > and finding out async fre hasn't started the freeing yet. Just free > all 64 entries in the swap slot cache. It is similar to the old code > behavior. > Yes, it will have the long tail latency due to batch freeing 64 entries. > My point is not that I don't care about heavy swap behavior. > My point is that the app will suffer from the swap strom anyway, it is > unavoidable. That will be the dominant factor shadowing the batch free > optimization effect. The original optimization introducing swap_slots target such heavy swap use cases when we have fast swap backend to allow higher sustainable swap throughput. We should not ignore it. And I am afraid your current patch as is will hurt that performance. If you change the direct free path to free all entries, that could maintain the throughput and I'll be okay with that. >=20 > Or do I miss your point as you want to purpose the swap cache double > buffer so it can perform better under swap storm situations? >=20 I am not actually proposing doubling the buffer as that proposal have its own downside.=20 Tim