From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB0C4168B3; Tue, 14 Nov 2023 09:54:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="HrqJG87U" Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACA2F194; Tue, 14 Nov 2023 01:54:06 -0800 (PST) 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-out2.suse.de (Postfix) with ESMTPS id 276141F86A; Tue, 14 Nov 2023 09:54:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1699955645; 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=/6QA4vhf9gFLQunzj8BiplEisko+lan8tAZakysSnAE=; b=HrqJG87Uy7vC6THv7iJmclQ0L/Nxw78BjZL6GAnFanuhZKBAssKD+iDEB897QaCMQh9gGH 2OhAmC3TJXiceO+687r4+bKjIzQgJuursJOTLkwdL/mUHWfdaW0uL7c1Tc8eHj8DAP/rZG kl+2dcSfNyfSzD82rRJ2WkL2YfNc7fA= 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 0BB6E13416; Tue, 14 Nov 2023 09:54:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id DvJEA71DU2XRHQAAMHmgww (envelope-from ); Tue, 14 Nov 2023 09:54:05 +0000 Date: Tue, 14 Nov 2023 10:54:04 +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: <87edgufakm.fsf@yhuang6-desk2.ccr.corp.intel.com> <87a5rif58s.fsf@yhuang6-desk2.ccr.corp.intel.com> <97a3dbb3-9e73-4dcc-877d-f491ff47363b@vivo.com> Precedence: bulk X-Mailing-List: cgroups@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97a3dbb3-9e73-4dcc-877d-f491ff47363b@vivo.com> Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -2.80 X-Spamd-Result: default: False [-2.80 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-3.00)[-1.000]; BAYES_HAM(-0.70)[83.32%]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWELVE(0.00)[23]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[intel.com,kernel.org,bytedance.com,cmpxchg.org,lwn.net,linux.dev,google.com,linux-foundation.org,redhat.com,infradead.org,huawei.com,gmail.com,vger.kernel.org,kvack.org,vivo.com]; RCVD_COUNT_TWO(0.00)[2]; SUSPICIOUS_RECIPS(1.50)[] On Mon 13-11-23 16:26:00, Huan Yang wrote: [...] > However, considering that we need to perform proactive reclaim in batches, > suppose that only 5% of the use-once page cache in this memcg can be > reclaimed, > but we need to call proactive memory reclaim step by step, such as 5%, 10%, > 15% ... 100%. You haven't really explained this and I have asked several times IIRC. Why do you even need to do those batches? Why cannot you simply relly on the memory pressure triggering the memory reclaim? Do you have any actual numbers showing that being pro-active results in smaller latencies or anything that would show this is actually needed? -- Michal Hocko SUSE Labs