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 76815C4167D for ; Thu, 9 Nov 2023 10:39:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A75278D00E0; Thu, 9 Nov 2023 05:39:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A25A48D0073; Thu, 9 Nov 2023 05:39:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9140C8D00E0; Thu, 9 Nov 2023 05:39:58 -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 7F0FE8D0073 for ; Thu, 9 Nov 2023 05:39:58 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 58E6B120DB4 for ; Thu, 9 Nov 2023 10:39:58 +0000 (UTC) X-FDA: 81438070476.11.2C49423 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf11.hostedemail.com (Postfix) with ESMTP id 548FB40010 for ; Thu, 9 Nov 2023 10:39:56 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=g76LmZZa; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699526396; 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=bAjTyM9LFw47Trcwx9e2QuYQewdjj60T+GRkl+OrN1k=; b=WGI49DvZMcUvSNM6iXi22k8150+84OV/+dtEeNygMZBUn4c+3hmzzWOwOmsVJGhEZyZoyG /KEbc3FA3Tg3eucf/iBfTfJY98UFSuUKTl/hBdkW6dHtSpe4iZpHG+Jg2lxZdXF7RqmVpc oOjxXHFFUamRcKxlp4Zs/OTanbCmE6s= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=g76LmZZa; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699526396; a=rsa-sha256; cv=none; b=RY5NL/UYV1G+d19ZxtocHa1xf7ig9XMQ3AiVd6mYsPhXdNcjYZxlK+HWz6FjC/n0ehqC8l 4vw7PRBiPIvjzhQPAzcJQnF96Xed+WiiLcFEOM+LYkLY4k2bFtY+Xh2tPIXXUXRFqaUmMp eJy2tTqXxDf+w14ik0gk+fZzXpEGv38= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 932FB21984; Thu, 9 Nov 2023 10:39:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1699526394; h=from:from:reply-to: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; bh=bAjTyM9LFw47Trcwx9e2QuYQewdjj60T+GRkl+OrN1k=; b=g76LmZZaCVFV74XvHWubphH/jOwnX36d8EfMeL8WgzfDc95tnFrddhcLnYN4+4FUY7FuIx iSdgdSoqMHV8LjE+ThOpJ/QEJWKi/Wt4OxF4tDd54EmKD0gj732XWfMXP16rCxE7EzTRYn a/rk/n+W9TPZYIX7OvV1DPp3qf3YoaY= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 82D5713524; Thu, 9 Nov 2023 10:39:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id fG3mH/q2TGUEegAAMHmgww (envelope-from ); Thu, 09 Nov 2023 10:39:54 +0000 Date: Thu, 9 Nov 2023 11:39:54 +0100 From: Michal Hocko To: Huan Yang Cc: "Huang, Ying" , 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 , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, opensource.kernel@vivo.com Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim Message-ID: References: <20231108065818.19932-1-link@vivo.com> <87msvniplj.fsf@yhuang6-desk2.ccr.corp.intel.com> <1e699ff2-0841-490b-a8e7-bb87170d5604@vivo.com> <6b539e16-c835-49ff-9fae-a65960567657@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6b539e16-c835-49ff-9fae-a65960567657@vivo.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 548FB40010 X-Stat-Signature: 5dz8way1ifhf5hanyeqwpfxe8r1crbgj X-Rspam-User: X-HE-Tag: 1699526396-67999 X-HE-Meta: U2FsdGVkX1+qOP4hwEaqHAy3Z1AzqmO7hoi6fj15XtzS4XU2Q9TS+93N0zCAdvIysq3cF5/KDR1chq82sIiFhVbGNO1lGGvL8tEVfBoPt8/JIqiVMpxe9Yq3hhzioPe+kJAEKuygn4seR1lLm18WnbvKXgyPX7c4g6sPqhZd6witR9KftV/IeMsM/MHBQlmzSTXioQY32gSfwxfOWg1oietQnymVNQRl/mHRAiEauvPRnqCbdCoDnnqSCQdlZLJg0nF4wMvEjCd8IzaL02fZE1IWbgqrTlmj106ay7qT7y5yNZ4StvmIOQBpIBErYlrxtewz2Kukh5h8NZLSwCvue/eXvmaFviPQs5KevSSirbP54FVNagU6HAn9RH+dHgWw7mfBHKD0zXp7jO2CCkeCEyJl2lNIz3EW1Pdr8/Gjzpf2LnJJhoaYaz2+20sdz2zkArd1DJ2K3h2nDeamD9bboDre0So1u1k0TS8+M2sAXMWtO5XV56mixR+/olkHrsr+8AcHIIPBc5dFvG8sLIweyEFP6TqmOPFznZdLli/BIHkaqgRNTegqeuC48gPQ4prftPxZfYU6+9UBPNsYPAMDsFCBtOmhCY0zUI2swIeh00hHXI+/hp7GkYhrnqqOlMmGoJNC5sFfuLoV9EKJKpFFjxe92o6aInNii37/ZwmWnskXaaRsIAE8JSKfqpm7luPicu0YBfLQNmV3vw7+14SN6ITqGSdf0sKrCPYrz/75GAwo5f4DfbTKZSeRmXqGr9lTj2gc01tNFu6oG3/vpIj53jel5ygnPa97sCASxGo4upLhUr3UtyldnfuYqFfhiwC95PZTzaAknCKDRyL8NS+STmeTQzpsdFEMmSrZWAMc7mg8FbPbSiRnmgOXTwYHcbimEsqxrBS2WcyNdv7FgjP3b7z++WC6Ip97ZCccVIBxOCZQXyRO7Ay9vhmab06wgWdS4IJRm72s6vW425bSVsc Fa+xL9zM UftChzuBK28kOdb9dEj+8Oq5/YfbBvlHbra8KErCoYrdyrxN9X3DHJaMiZ7gCPfsydCFZNEfiGBjZsL61VNYTPSrBWMs4DuHDz3S29ilB9juDQFpGA7n75m1HWsQGf84wrqdhjspgLZWRIc4BdtmNEUFLrKfTq1qXwKbEg2qabOY/uoQ2iZakAEAiVp6AVl2Axyn9qJ1aZP/PBKzS3yebrqSpwqf4xpMpqrlMI/gdn5ZTqIwSIFW7IealDwCG2e6TKX3Qds3Rwmml5C6uAEi81/fxLWqBdv7LB38HPtnYX2Eu9yNt9LiAaJsqt1rH/wzCWJdtZm3f/LV4BA64GqRnb2UTJ7NK/QiYmiGGwLakWWgwod7UOfgFOXhRcF8JxBK5uIxNwIYOP0oCSlLJrw77GL0FWA== 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 Thu 09-11-23 18:29:03, Huan Yang wrote: > HI Michal Hocko, > > Thanks for your suggestion. > > 在 2023/11/9 17:57, Michal Hocko 写道: > > [Some people who received this message don't often get email from mhocko@suse.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > On Thu 09-11-23 11:38:56, Huan Yang wrote: > > [...] > > > > If so, is it better only to reclaim private anonymous pages explicitly? > > > Yes, in practice, we only proactively compress anonymous pages and do not > > > want to touch file pages. > > If that is the case and this is mostly application centric (which you > > seem to be suggesting) then why don't you use madvise(MADV_PAGEOUT) > > instead. > Madvise  may not be applicable in this scenario.(IMO) > > This feature is aimed at a core goal, which is to compress the anonymous > pages > of frozen applications. > > How to detect that an application is frozen and determine which pages can be > safely reclaimed is the responsibility of the policy part. > > Setting madvise for an application is an active behavior, while the above > policy > is a passive approach.(If I misunderstood, please let me know if there is a > better > way to set madvise.) You are proposing an extension to the pro-active reclaim interface so this is an active behavior pretty much by definition. So I am really not following you here. Your agent can simply scan the address space of the application it is going to "freeze" and call pidfd_madvise(MADV_PAGEOUT) on the private memory is that is really what you want/need. -- Michal Hocko SUSE Labs