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 E8F99C4332F for ; Tue, 14 Nov 2023 09:54:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 777428000C; Tue, 14 Nov 2023 04:54:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7279480009; Tue, 14 Nov 2023 04:54:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EF468000C; Tue, 14 Nov 2023 04:54:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4E30480009 for ; Tue, 14 Nov 2023 04:54:09 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 23B5DC099A for ; Tue, 14 Nov 2023 09:54:09 +0000 (UTC) X-FDA: 81456099018.17.E0927D1 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf20.hostedemail.com (Postfix) with ESMTP id 12EB11C000C for ; Tue, 14 Nov 2023 09:54:06 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HrqJG87U; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 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=1699955647; a=rsa-sha256; cv=none; b=y8AAfflH2pljXUEtfjZ2Gvu/DmJcOjWb93X9zyyu4Afo3ADB1rckvn9TVOT8hJJwcj6thj 7FQIe4TCgh5rfYuMHR3D/0I3HpFIjYkhFR6ONnf42wuBe7kTphyZAPatEhOjpQe13m3t6D ceN2jojlKYXPS85Wisv3zfkvewbjKAM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HrqJG87U; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 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=1699955647; 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=/6QA4vhf9gFLQunzj8BiplEisko+lan8tAZakysSnAE=; b=kAgJCaQy353MS3PhK1watzF8248usoN3CzdbqYrsA7IEf0AJ1qU3aXLITxCRi8Gjk/tSfG 1lkf3RAeIb7dT01sYfGT2Yv4gY2QcfSpFae4Q9wS0yPbISpaOX9M1jOV5asdePeh2Tt/pI /feum1H6lBxluRwQXr8QD4RG0ztUqJk= 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97a3dbb3-9e73-4dcc-877d-f491ff47363b@vivo.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 12EB11C000C X-Stat-Signature: we7abwkw5e6wg1rmufsnuj836wteepf1 X-Rspam-User: X-HE-Tag: 1699955646-674793 X-HE-Meta: U2FsdGVkX18+f4DNZMJMDMP21qcZvbzUdwBGY1XjIg0R6SK+PUFpIKuqh5XCLIIZV+tnmfPA02EN+4PFxDkqTxGPCuWEO8RAaqL0h4q48J6pvKKACZdbc7mVa+I4XjAoQiZnqmRdt5yEKagauvqAS/55SwwiYb8I3biJpX8ityYd3X3W3FKdU4mlQorr5RhmWHacUCe0czonGqBqMuj3Cf1HRJKzl+qMy1O2sOx4xxVwV8lTvbNr/vG80NbNxsgCrPJWnMttWBvvRojW27VsZMORZszeYpnoK1YQRvoN1ig9X9tJMkNsW6Uobr1FtG2gvnvg8zyxIMwJvXDLfpxupHpPE2TGCSqNV9gRUmnEqnuo6v7XeQVVhrPcLYMlY5JthAJAygS9Zs5exG/m3VFFykl2plAuEYF0IwDdl0TnWJNy7mHGVgdZxgfRqjFYHFuL0AxMEtafcYPKhSmNzZnteaxLMUbF9T25KFZpTV4DnqzMSvoAfjtdHnK58DbdB4OphorOtUR9YYCx755vWiVpkKw97tngMy/cPgsgOJlDRIDwN1t+OwKX8RQzvvyNh6rBZHIjyMERyOXt/Op603GLOco3i36oKtchgLEqSLAw1UyD6ZGdY3vR10aaFe2oUPm+Bh/IS7LNipGUaYIGob/qtl99nAG0PFEfuZt5PqvFqdV0rFcFGHOVUzSjTTPHbcL7hBtoBTxxUVdjmRnu8/CThEmIHB1A+NXj2qwwHqKSaCGFF/45SU6Z4AuQ2SAt/gZAmkNYSI/FG1/SPOK0TqHRXuz05x+F+3OGRI0INvNQE+X86XqZrJeaJRoQ9WEIIYFZ/Ra43UvRRr2quarhDMPwFn3kGm53fQD9r+AVeGx3A1bWIH8+bHTOw9gLNzpyS1U7YFW1dTW0TO4aqu8lKtj6XnjO1XPQcz8uGkpCc+92RMtPY+4lHkXMYzz2Ez87/s7JA1HwIM8qGTu9QD0mtEX 4QSy9c4N Xzu1v+msY7ON96BwzkJSgOs9t2snvIYg0zEcHg3417fI3MMRO2QvTk3afkXzBf/Pov1o5y1WkCFN+7naeGzDCBZJwShKZyzpAJdsLgv28/BW4aDyd0NjT5pNaZxrUy3S7bYtINtvWZnbainR6AOm7wDf8l+cYVie2PfpaL1BQzdHHBGh+10woqpvSzxXyqjQxhQAT+Z7+xfPDYk44sfXgem6cEDR03gRx7rVTskFJIRd3/f2BQtn+EFJpl77nVpohXtNb 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 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