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 359AAC07D5A for ; Mon, 27 Nov 2023 08:14:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F2026B030A; Mon, 27 Nov 2023 03:14:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A2EF6B030D; Mon, 27 Nov 2023 03:14:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 369AD6B0311; Mon, 27 Nov 2023 03:14:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 23DE16B030A for ; Mon, 27 Nov 2023 03:14:06 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ED655C015D for ; Mon, 27 Nov 2023 08:14:05 +0000 (UTC) X-FDA: 81503021250.01.96043C6 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf06.hostedemail.com (Postfix) with ESMTP id 09383180008 for ; Mon, 27 Nov 2023 08:14:02 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DfKJKz7i; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701072844; 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=Gwrbmwqj22dZQcUFeolhEXpQccpz9WINwGmmOJEIN/c=; b=YijKCuniwXxnHRET+k9UylrVTN8S6DwIhJIlT5VYpTBnVSjfL6339fpYj3rnur2vs3ZoM1 JB3LiBWzjIbXajAYyva028m/bEcbRn7RTYtuz9bT8v76eomXiQnlnGbIWYl3YtbfTaq22X 1Jey7Qg7CVcW+vJQDZR0XNcKSnpFBxQ= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DfKJKz7i; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701072844; a=rsa-sha256; cv=none; b=CuvjRGqhhMMJGNfFWGzFpEIgnPU7ot4KPxVwTqZhbtpPcJzeXpRXMV3kULv3ZNZmrchONJ RC+Y/Y07kgJcFwsjtizg96AiI8nBczGyc4nyJAPRGzAyVvZ2YGhP2KLuOCtyZ0qvq+5CZH M8F0hrPJqENPAh1blHgOZgj1WVAoAtw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701072844; x=1732608844; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=/gVTlgLrTSDTMo/7KNUnEHr8qrr6Id/gcu9gUpWeGvQ=; b=DfKJKz7ifU4SMvvRABAqjlGF9msuu5aa0dV1t2daIVXHN8Y+D1FiR1/t cWyOONL75S3DMiGVmQxPPdYwnCKxOTAi0y3XLjVGczDehY5twgkY1OZ0C KG5pKA75ZCDhBgUZqyXKyb/ItDM4ss/ssr21O79Wj61e+tEWUFZGL91Lo Hq5qzOzWwbjJm6PS7X/rvYzPM4Z//79OZsZQKppg/6+G0Cf9yrGKL11e/ dmCPY+AaR4OaEA9MMthkn57Hy7PU/tdde7+/ZkukXoqjwdf83z/im7Q5p fajT8inMwRH2lucN8ES1DgUwTXx6kB+E3SQjPw+QitiIWtuVbL+WeribK w==; X-IronPort-AV: E=McAfee;i="6600,9927,10906"; a="11356532" X-IronPort-AV: E=Sophos;i="6.04,230,1695711600"; d="scan'208";a="11356532" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2023 00:14:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10906"; a="768101582" X-IronPort-AV: E=Sophos;i="6.04,230,1695711600"; d="scan'208";a="768101582" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2023 00:13:58 -0800 From: "Huang, Ying" To: Chris Li Cc: Michal Hocko , Yosry Ahmed , Liu Shixin , Yu Zhao , Andrew Morton , Sachin Sant , Johannes Weiner , Kefeng Wang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space In-Reply-To: (Chris Li's message of "Sun, 26 Nov 2023 23:42:11 -0800") References: <20231121090624.1814733-1-liushixin2@huawei.com> <32fe518a-e962-14ae-badc-719390386db9@huawei.com> <87msv58068.fsf@yhuang6-desk2.ccr.corp.intel.com> <87h6l77wl5.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 27 Nov 2023 16:11:57 +0800 Message-ID: <87bkbf7gz6.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 09383180008 X-Stat-Signature: zap9jokn3oc88tzg6i8nikky1jquegsx X-Rspam-User: X-HE-Tag: 1701072842-527680 X-HE-Meta: U2FsdGVkX1/TxetjfpO0B6LTf+Aqj7wZF2TVQ51Xu+aDSENujU8vYgh52LvFgYfzjsBVx8PWUAZ42teI+79GrLq+H+TA2yg9/wGahjro9s0Tde7R/3psAUZAxMN6DTWZhwKuoTzf1By+ijLB9VMbDY9kWMeGNJxc4EuYczb63vD14n9hFFPIAuoOCSYja09g6FmQslNRuGnsj4rFzFv9GPYlLYlAaVZ1hcp+qLOEK/r9wSxzUF3+UgGITTxo9uxAN9Pmaf58vVLvn8k0bqHcH8W5AiEQuWi4u6QWQSKvyPBXi30DzH4Uzzd2Bb/oj9fjQYsHu/obrhfsRe0G1eyw68CIaVjxqkDzg0p1RpFvvJ36hnHJW8lz0AgUE6L4TdWsmALp4DdLk2XisYWUUbzfkMfrMY+P/k4kEIiEp98KBL2vY2fmDQ1d0yKhbBNniqAq2slrK1YEDpQDpAMytzQMBPeS8gWUMXBVIjbQ5q3inarhBkOK+qtqYhj5MpKkq0hCmaEbW95o/2G/xoxcjROZpMX2AUcom6SraYbZ4M9TtLDZyvaBgWGsx7IB/Gp/f6BOLEPpLFguD9NzNvJSCVm34Nqst+9pHNDmnHQUErfiWMjcQm3iQM9aBYhTJlAqYBv6mqPth1WW2iamWZPF5liKT3taiC5RseK+zUBgXCbaTsskK8r6IhSgvoMm2N2owr71jaqJKyqcVK8zLE9eAF/tjR24WD3ZrYKU+g82t+i+8WUz5qoIGHERhTAgwlQ7YNXLytUjWce25zHboQ3L+VyflEyZ0Sj+N23TGWb8x/RiZzxnuFFbk/NFM9vSNHHdn9amYqzfBz5jWVJW9UP1eTkg4VsYq/+C3d8IfvsE79MUXk1+2/QCLZRe8qiRCksxN/tkXxThi5S2ELBZJQpAqKljJC6sRG85Xf2cU+tY4l1y94cyh3ux+sCDg1FuN3aEtZtqjm54b6tKCyZunu9ya8w p4DncXNL iAQcglulnXFJ3hKU1mYs3HXXzIhG6jYY+iICESKtlK71gUbe3X2qDb10xthn0nJpb2eq+YF+EhKaGKc+b7LKVVjXYN7fwNSvjelMmbWYy/T66muOaW8zmGYKA0sBYFRCKEt1lLhppoGUC3jKf+pnGZPfXCV1gzQ/Oh1btk5VUceUbR8+2bgRhzBithRNi7i/pl1+qTrkTtbpLx9p3+a0ltoN5PSuVSv2czh3GR6wUxP/COAiNkCF4En5B5rpwswaIRlal/oWUAkEWp59V9lhra+bEiGLTWy0MdNBu 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: Chris Li writes: > Hi Ying, > > On Sun, Nov 26, 2023 at 6:36=E2=80=AFPM Huang, Ying wrote: >> >> Michal Hocko writes: >> >> > On Thu 23-11-23 14:15:59, Huang, Ying wrote: >> >> Michal Hocko writes: >> > [...] >> >> > Yes swapcache pages are indeed more complicated but most of the time >> >> > they just go away as well, no? >> >> >> >> When we swapin a page, we will put it in swapcache too. And the page >> >> can be in that state for long time if there is more than 50% free spa= ce >> >> in the swap device. >> > >> > True, but why is that a problem? If you encounter such a swapped in pa= ge >> > on the file LRU then the page should be referened and as such should be >> > activated, no? >> >> This just means that anonymous pages in file LRU aren't temporary or >> short-term. So we need to consider that. For example, the original >> method to balance between anonymous pages and file pages need to be >> re-designed. The anonymous pages are considered hotter than file pages >> in general. > > I agree with Ying that anonymous pages typically have different page > access patterns than file pages, so we might want to treat them > differently to reclaim them effectively. > One random idea: > How about we put the anonymous page in a swap cache in a different LRU > than the rest of the anonymous pages. Then shrinking against those > pages in the swap cache would be more effective.Instead of having > [anon, file] LRU, now we have [anon not in swap cache, anon in swap > cache, file] LRU I don't think that it is necessary. The patch is only for a special use case. Where the swap device is used up while some pages are in swap cache. The patch will kill performance, but it is used to avoid OOM only, not to improve performance. Per my understanding, we will not use up swap device space in most cases. This may be true for ZRAM, but will we keep pages in swap cache for long when we use ZRAM? -- Best Regards, Huang, Ying