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 582B6C4167D for ; Thu, 9 Nov 2023 03:18:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A912E8002B; Wed, 8 Nov 2023 22:18:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A416E8D0073; Wed, 8 Nov 2023 22:18:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9301B8002B; Wed, 8 Nov 2023 22:18:04 -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 8486D8D0073 for ; Wed, 8 Nov 2023 22:18:04 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5130980CD0 for ; Thu, 9 Nov 2023 03:18:04 +0000 (UTC) X-FDA: 81436956888.15.31B9151 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by imf03.hostedemail.com (Postfix) with ESMTP id B13B12000B for ; Thu, 9 Nov 2023 03:18:00 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="V/GGNZjW"; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699499882; 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=qWIes5LEo7WJDd3/MoVRWrHKNF/FnnubPVZAVSdvbIw=; b=4g9nMJMKGIgM7n2nLchwhCBCj/lX8qiQxPw+gV0rL6wMJqWYViHzkO6aQqD0CY1XnpNhZs IkJmZ9f4JfkZ+DXSZ1Hi0QKzorhUySwhCFC/Ph/uc1v7/xSI8wcp3o0rsiHcqZJcqh0e2+ kz8+qO2Aw3PcgMO9MGjKp5H/eouxt1I= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="V/GGNZjW"; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699499882; a=rsa-sha256; cv=none; b=8MSFiYJmXrmH6qPtsJBS7DEVWWGgHM21+zNURw3K2xbqsoNlp/2gD/5GHNVe2f/3JX6uS+ t656kELsVo8zm7S9jC6wJ41vkW463d3HUmSBDfVRHTGaLTNsO0wkuLyZJ7bnd9/3vRnfIw B6kaUAwhlpYE3unbT/rjHk+p4KmNDD0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699499880; x=1731035880; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=ynC47GQwYlSIUpMUpstR+O3T0lqTMuFurlbi3ahjlAw=; b=V/GGNZjWlRmD1nPBnxWlJLTqcTABKt003UGNvhbocUh9Wfy3Ie6t+Yk1 LwLoBO0LbLdlFg6n93at7+ffSJelypAU1Dtp7Dt+vESugjNTQxw/sZIwX d2eX5L+eoyGw2i6km3d4uTS2aMdkIVqdB5lN3XnNvv17uXV7psaeFCsiI /uahdQyzecQOfSpVWScpzrrfX62rawaA9I9m6IfKYNcvHaxuqfzuUCvc5 EXMBawU0Q7bDNbeGwIcLv5Pc8umNAx6eqqsX9wc7NPy0YGcMRF67uqxae fXbad47lZfFM4KAoiaOmaWby9tHe6sLRKx/9y46xkDCyB6L3gWpaUeNF0 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10888"; a="421007298" X-IronPort-AV: E=Sophos;i="6.03,288,1694761200"; d="scan'208";a="421007298" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2023 19:17:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10888"; a="936715642" X-IronPort-AV: E=Sophos;i="6.03,288,1694761200"; d="scan'208";a="936715642" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2023 19:17:53 -0800 From: "Huang, Ying" To: Huan Yang Cc: Michal Hocko , Tejun Heo , Zefan Li , "Johannes Weiner" , Jonathan Corbet , "Roman Gushchin" , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , "Matthew Wilcox" , "Kefeng Wang" , Peter Xu , "Vishal Moola (Oracle)" , Yosry Ahmed , Liu Shixin , Hugh Dickins , , , , , Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim In-Reply-To: (Huan Yang's message of "Thu, 9 Nov 2023 09:56:46 +0800") References: <20231108065818.19932-1-link@vivo.com> Date: Thu, 09 Nov 2023 11:15:52 +0800 Message-ID: <87msvniplj.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-Queue-Id: B13B12000B X-Rspam-User: X-Stat-Signature: kzbkhsnrzji6fbux5x4xoo813c4xri5k X-Rspamd-Server: rspam01 X-HE-Tag: 1699499880-30064 X-HE-Meta: U2FsdGVkX18dBwfeQHmL98rm6xmt1iLX8LrAY+IWxn8pNUnyIDZNzoYhUepH9dHpWE+IG8LVEk1RkuSapj4M6wx9Eu7PSuXi4/9ZSdy6qG6xtsZAx3Q7xSUJ/nUlt9DWaBwJX3RJ+Arn+huK6JJFkQPJQQ4xrjpoKPMlwdlYa+wDy4LfC7LgwTRy8BafAhiWDzKL894yI1zLrrUKR/oUjgg8T4MqWfeQuy8EgZ4DFTJ8IKTA3R872WUkbz+oF+H6daxq2vVfU0u5vP+7SNJEU/0kVf6eaIhvbAOiy2iCh3IREcQNsU/+kB0PKp8jkqEmUtHQYeSNAmCtHVYOfwVAP+QUAJYDPD98mFEM+8JuBx0jQc9qMen6YZ5+5NopcI21uUPiCGq0breA1G7TBg0z9yXYJS3WSN7sGzKnGMQ13sAK5Q8yAKQ0Zj57t7MZM5ltY+oofWY+13brfXANm5R3eRRB6SOzEtOmMcotNE2KffB3D3gUXtftIPZz/R/5QRQanduuUt2Y3cktuJ8ytunAQ2jy+KcjkylhiSMyRoIo1FpwLQD7/Wj4L7GZOwqEUmPG0dKoeaols5y1TFzWQBZvO7SWdvhRUU5lHUQJ7JGxdZ1BUY5gmWxo22siFs2lo8EElr8RLYFvwtNfASL6XuDk0h1F6bpJBiQG6Dpd2+RxGYdvuKsla2/499QAqyaz9dqMu9VTLKIbOvO3S0RdQNI3hNKKf5QG09cmPikqDBFOSV2pwoE1iJWVW/s0OLWTmGAd+c/vNvTFfnM0ggpibynmvvUKrImndI79cCLc3OIdAxljYeRe0BALQoMXLNz+gdJSkEJAYP9esBEcdZfQyszVyuun9suzuO6AXxNBM6BzqkYzgFPItbYv0OwfVJn+XjjsghQU95GWKq7Ufp+PCxXqG5wqZ4EuJ+h1dsyDLArz6rnOWSC1uuGzXudryz8ABfxrp+Tb15RuEu0mJ0vO5mc aVps2ejW Ui5xTXS83GR/LiBnO6DhKLDYMnyx8/kHgMtvGbsCBHe/RGlqNIm6EvkEP969eGokIINgA6waUqKMIoBjlEIhLgsyT67VXXjdLT4Ws7G6WF28P3bBi9/zke6fR7+zDBkGszNY2hBivElNbmvERG4ilemlGVvWo+lUKF+WTAzdY1ErNh6ZZA3mcQHr0d7nYTjsaOnsucHspp9NdUm8qrexzbdaFuQVUpggchdybadjGRxzSncntyhpuQDVQJZG+YJQv6vpfMjGlsm8KNJICDBG3A4ZJXdU2Zjw5s6YiHBdkiRBbdmyetCXDYpaSNB87laskNTzvnJdZKpjMVMmECL+5cc3wA4O/qbdluHt5s0lBBb6NxCXsAhd6Ajs3mMfIH3QQM5SIjzTRbHvSFEYTR+D5gfVdD97vcWbIR0U3KUY6gVWUQV8= 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: Huan Yang writes: > =E5=9C=A8 2023/11/8 22:06, Michal Hocko =E5=86=99=E9=81=93: >> [Some people who received this message don't often get email from mhocko= @suse.com. Learn why this is important at https://aka.ms/LearnAboutSenderId= entification ] >> >> On Wed 08-11-23 14:58:11, Huan Yang wrote: >>> In some cases, we need to selectively reclaim file pages or anonymous >>> pages in an unbalanced manner. >>> >>> For example, when an application is pushed to the background and frozen, >>> it may not be opened for a long time, and we can safely reclaim the >>> application's anonymous pages, but we do not want to touch the file pag= es. >> Could you explain why? And also why do you need to swap out in that >> case? > When an application is frozen, it usually means that we predict that > it will not be > used for a long time. In order to proactively save some memory, our > strategy will > choose to compress the application's private data into zram. And we > will also > select some of the cold application data that we think is in zram and > swap it out. > > The above operations assume that anonymous pages are private to the > application. If so, is it better only to reclaim private anonymous pages explicitly? Add another option for that? > After the application is frozen, compressing these pages into zram can > save memory > to some extent without worrying about frequent refaults. > > And the cost of refaults on zram is lower than that of IO. If so, swappiness should be high system-wise? -- Best Regards, Huang, Ying > >> >>> This patchset extends the proactive reclaim interface to achieve >>> unbalanced reclamation. Users can control the reclamation tendency by >>> inputting swappiness under the original interface. Specifically, users >>> can input special values to extremely reclaim specific pages. >> Other have already touched on this in other replies but v2 doesn't have >> a per-memcg swappiness >> >>> Example: >>> echo "1G" 200 > memory.reclaim (only reclaim anon) >>> echo "1G" 0 > memory.reclaim (only reclaim file) >>> echo "1G" 1 > memory.reclaim (only reclaim file) >>> >>> Note that when performing unbalanced reclamation, the cgroup swappiness >>> will be temporarily adjusted dynamically to the input value. Therefore, >>> if the cgroup swappiness is further modified during runtime, there may >>> be some errors. >> In general this is a bad semantic. The operation shouldn't have side >> effect that are potentially visible for another operation. > So, maybe pass swappiness into sc and keep a single reclamation ensure th= at > swappiness is not changed? > Or, it's a bad idea that use swappiness to control unbalance reclaim. >> -- >> Michal Hocko >> SUSE Labs