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 DEFF5C4332F for ; Fri, 10 Nov 2023 12:32:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 457024401CD; Fri, 10 Nov 2023 07:32:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 407394401C7; Fri, 10 Nov 2023 07:32:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CD744401CD; Fri, 10 Nov 2023 07:32:37 -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 1D97B4401C7 for ; Fri, 10 Nov 2023 07:32:37 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E271B1CBC29 for ; Fri, 10 Nov 2023 12:32:36 +0000 (UTC) X-FDA: 81441983112.14.EBC0201 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf29.hostedemail.com (Postfix) with ESMTP id 08880120017 for ; Fri, 10 Nov 2023 12:32:34 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Clxy+TbX; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699619555; a=rsa-sha256; cv=none; b=MedgQ+mDX6cr4PGhMfA+frm6bRjR6tPnacLOS/rvgcAEbUG+zYXYd/nsNO49EcpUjc8zJM BL2q+v2hEi+IpSb3V88fFm3mH0KZ8C5LMLtoCXPzGDe6srVQ+bpZAHSxGAp4r2vtOgMsi+ yZq9WH5J4ebAZg3iWkxfVQIHjIP0mck= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Clxy+TbX; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699619555; 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=CjDgsL3wVenpcsZH5g+MB4etd9XiD3ofoHzynlFpI3Q=; b=KL5gHQRPIesMBq7kOYW7sx/z+9vjnaxiXyIXVNZNFDQu8Fs2WtnfAhbWCXpat4Dw+LAskt cYBTLNkNQmK3SjJmdTLojXS8JSrAGlqmV3LEuc7n6CcxYDL4EbRX9PXogXT/frKbGsZOmM REOnsHYsMcQjjjwzZfLUSlMH/J63gak= 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 CDA7E2198F; Fri, 10 Nov 2023 12:32:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1699619552; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CjDgsL3wVenpcsZH5g+MB4etd9XiD3ofoHzynlFpI3Q=; b=Clxy+TbXjYlMgo44U30LFajMdpGxRz2QVANTOELTG2L39Sn+lZ+bmCRSSWt9YVmCgN8NW7 j6kHba8FKOOq550b4qXfxkB992H4gB1BC+YZt4YmL/swXh7VAOj3r9Mzj+eVzpxJLTLAjZ cYDF0kQFr/7OO3pLjgzGEio4TdkBbmo= 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 A9164138FC; Fri, 10 Nov 2023 12:32:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 24VMJuAiTmX/HwAAMHmgww (envelope-from ); Fri, 10 Nov 2023 12:32:32 +0000 Date: Fri, 10 Nov 2023 13:32:31 +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: <87msvniplj.fsf@yhuang6-desk2.ccr.corp.intel.com> <1e699ff2-0841-490b-a8e7-bb87170d5604@vivo.com> <6b539e16-c835-49ff-9fae-a65960567657@vivo.com> <87a5rmiewp.fsf@yhuang6-desk2.ccr.corp.intel.com> <878r76gsvz.fsf@yhuang6-desk2.ccr.corp.intel.com> <78128117-ce70-47ef-b7fd-10c772b1c933@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78128117-ce70-47ef-b7fd-10c772b1c933@vivo.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 08880120017 X-Stat-Signature: mabm59anwkzbstxajruawo4n1rtmqxbw X-Rspam-User: X-HE-Tag: 1699619554-93533 X-HE-Meta: U2FsdGVkX1+qBbqodIm/v+0G9B/AVG/QqeyvmkYlyVDhh9wn4I5ZXhmvb/AABx8NXdsHrLsBM0CtzGo7k1YEfV3t0AixThjCZuRT0lVLwygLVlTUMIaeEM0//m4WKSCjBMfStba2qnKISzYg5xYT1WohB3ggIDQAjEdEVRdaLMI7bzuKzb3FjWA+i+a32YRATOMfLVxYkeutC/YomWx7JIUP4eWN8Il0oh5clVuqcDdN7A0z5QbY6H9B7Rpjkd9uvkOVejAVAKm4n9v2oED9nE56sTqmKRcT6EMRs+V4l9G3y1dWvP2+bIwqCSPQJF1RCbCq9+t5/8/x3ontz/0gti6AW3OqATCVgy1HLWp+il8nx2TY+5D0ZugaeGn26QiDHrH3I7O5WT9Yc2KQJxbSEZsam3ymGYkzuED7GSh8SST80EEsQUTOa0lStmuy/YtsLJtbBFPVv8s9afqf+uq/VSbqHFLWXP2+PYKwYwdfwWgNEBWKeuHtxEejkMS3uWAwMfFUEJiNRvQ4u0yQVDx0Fa7ofk3bNMiAtzEboRSC92Y/7Um6Q7HFtMWyc7HksrHNlxEdPy277HzctGAnO5bN1DUGNGvu1osOwSG9/YzKA48RpciU9LEAEjAaot8XHm+CBHDBhX2bjoGqVUkHTtd6nR1uWnrG0lEBNO6ks3R9EYWRz1vSt+SJTAjBJZXd4E+rdK6+JKwF1+j7OQdNxmPyMZeryBHrSiIYxZs4wYK0AeJpsIr/4QcROFLGNo7rfA5ftY5n7iqDbhje3SGlSGDz8CHv6Cx8b5B9pac3xG19o/oEMKr7yiOIRHkFsXAnRAHoSE53JN73S8cfhiaPjvAUcC6T0Be/ybLYU0W65wSqqA8C0uwavPL6MgeSTU1Mm0MySc1EEAZQeWgBKeTjS9sZ7sL3FHnDup8XpPaWc7TxaWP5EIIuQfo8GuZ4yUKPgk8EhiptYNXQvm+UJjyGhH/ 3Vr1Xe/E K18hyAG/FMXs67sEb72TOL3EbbquL//TTBrXN0NLPu2j+C2rq3/FIi+NiNiu6QD8QMzRGMCLLufm6ci4gUPK2hwltZfElztzs+7Ic2cXckHm+PNZ30724gk9fBZ9dGcskZZ2Cbh6QvyoLB9SsayXtzjgJpPqJXp4wk0ToXJfMy/KHWKK7h/ocTWNGSW6i0T5ieryw1QIfKAgXJaNm0od2n9dmUaN5NFH/K/0ZHZmFLg/WV0kSZlzizgnN97ZEvuiuSd0l 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 Fri 10-11-23 14:21:17, Huan Yang wrote: [...] > > BTW: how do you know the number of pages to be reclaimed proactively in > > memcg proactive reclaiming based solution? > > One point here is that we are not sure how long the frozen application > will be opened, it could be 10 minutes, an hour, or even days. So we > need to predict and try, gradually reclaim anonymous pages in > proportion, preferably based on the LRU algorithm. For example, if > the application has been frozen for 10 minutes, reclaim 5% of > anonymous pages; 30min:25%anon, 1hour:75%, 1day:100%. It is even more > complicated as it requires adding a mechanism for predicting failure > penalties. Why would make your reclaiming decisions based on time rather than the actual memory demand? I can see how a pro-active reclaim could make a head room for an unexpected memory pressure but applying more pressure just because of inactivity sound rather dubious to me TBH. Why cannot you simply wait for the external memory pressure (e.g. from kswapd) to deal with that based on the demand? -- Michal Hocko SUSE Labs