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 C8521C4332F for ; Fri, 10 Nov 2023 12:24:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B55B94401CC; Fri, 10 Nov 2023 07:24:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ADE004401C7; Fri, 10 Nov 2023 07:24:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 958FA4401CC; Fri, 10 Nov 2023 07:24:26 -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 859E14401C7 for ; Fri, 10 Nov 2023 07:24:26 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 61B541CAD80 for ; Fri, 10 Nov 2023 12:24:26 +0000 (UTC) X-FDA: 81441962532.28.D812CA7 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf13.hostedemail.com (Postfix) with ESMTP id 548AB2000F for ; Fri, 10 Nov 2023 12:24:24 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=cIHSZ08P; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.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=1699619064; 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=TEMlJTypraY6MioDn/TZVL4tcm3Oo4k57aQCpucll0g=; b=luhiGsww1GQWhXa8d9xtHncTCNRsdMHW0UAsP/QmxJR2bERl6M/zfDtorxdPyMGtoxGnU3 T/dSS0yOxtqark2Fxq6F5U55Xj2rAJZ5ZDg/QYN2IhSaC4wcoyMgtajoFaFf/VbQ467sXo 3Wevqw/aWFvobvZBHdXmTb2Wi8P/uJ4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=cIHSZ08P; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.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=1699619064; a=rsa-sha256; cv=none; b=LXRPeeJ98nufbGSFdbjQixgYYwQqdnq8rhLNAEcpM3Pf7/gl6rCk5hgQH5AO67oZIVWJzg QmGYhobBghySCVw/b0z4qq0TZbAjfc7e9M37j00dfDAYVli1lEDyN0WW5FTmp0peKVPj8s biz8+KarArwRxWdR5oQV9FMPtHCNuAA= 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 0A0BC21986; Fri, 10 Nov 2023 12:24:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1699619062; 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=TEMlJTypraY6MioDn/TZVL4tcm3Oo4k57aQCpucll0g=; b=cIHSZ08PXwgBV4D2RmTzbFq2GyGr5+BNUU+GuQ9Fp/jFC75c8eID5PAMgs6kguz0DrNQYI SbSO3khkf4I2EI3HmokhHYfmtDkbYdzfpJdJTAwA8MBEhid3yd9fqH5Xf6AAKlnTp5FY1j O7SiT6Gk3d39XEj9inJvHDcoTJPrWL0= 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 D9BD2138FC; Fri, 10 Nov 2023 12:24:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 01Y1MvUgTmXhGwAAMHmgww (envelope-from ); Fri, 10 Nov 2023 12:24:21 +0000 Date: Fri, 10 Nov 2023 13:24:21 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 548AB2000F X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 7put1toa5wa5e49z6sxzb6ak8t81ncib X-HE-Tag: 1699619064-787103 X-HE-Meta: U2FsdGVkX18k8IrGC+nDDYysZyphKn5H59AYj43yCKQuEKLiOVZ6QWpBMVlsDxrVDoRjUjOGc5wVUT6dWI8uhUvrB5stNhbTgctyfVqXuDnnT/AtgmivxD5i4v5mGrYEWSMagcNFUa2yBQhoGglkrNwde/KEHN3lMobjDKt4lwvqYCExQQI5SYnIXRhduhNEm+qvZB/H+KQIDugmLxAfmDldutMBe7O941JS4UEb3UxV4wE/Hg09RxVev/mUxWmNr2ugyCr/nlRR6Bm7v/kkTj8rpXUHsVBpvtKQ98gq8tvkHno0/qe9h469fkkG2i/eo25I79dxXVRzSHfA5Ng5/RJ9tBzauooGm72HMv9uTeluxPb++w9dUFcgxukU3eShIPPNkYV+FI2HDh2pzIMudj8Lg75fM+nUKt95VCwHkWZY+SVpWzHelFEEJ1cKcsyXTxZehDp6Unda8KT1NVymPgExX1/7lgWjaH8gFKuGGoru5adjcUnWTOrXm1tJ+0p8UyUkmgRhE0CT6BAq7WalpGh0zPZOD8v0trx67UeNpfKf14LI66grpYdJnotwg7rqGkQFzrNZr1e5nuxK/U/8MQrZ4W702a84pKHHQUpr5hEsDJ6i2y6SyvPFGekVg05myxHycpnJH8tjZe3mbSEwBBwKMjZBck1SnBQfbKD7XhawiufrZig1B2qdrvFRsXeBhvxgZwQOv/88U4+mE3t8EDIe3M8GYaKbVWIDbqvXoLJXu1fILXUODzePVYbZAZyktzIzXdeIGb25CegajOgpoFkcuS1ytYsTpNDdlGMmIthhGF+YXyKc5XLMYQEnc8WF4gqLjWJXARu2fG0UEv5EKaaXGubZ45AFzokmvZrCc6OHl9bIXLmRYiC0CyHfE/LBu7biOkhN6Q5x+Rn4O7i26r6GYqWEzYTmHShIDRydC8HUX+4KKr3Nh41hR6iRDa8HwYocfJMONcbTtGRO4E5 ZkRBitxe EpkFSQyyLjSShli/RqiQMZu1MGqInDZckMtZO3GWJRDCSvWaPO3yNdWKI9o0ZK+ueng89T3JiV3YMp16J3BXpVQIhJG1x9UTDK6ZWZ9GCZUgONyR96XV9XamQacA/Tu8n6l/Ohazlk4gWOJ0TcdveFe5ugUrHDkIiWHYqXmbM/VnA3LQ0GhJy4pkfMCVhvwcWrpVvslHWG9oJuKtmreMjMjJFVzBZDqrYp+Tz/peWodUTdjzXazVZio5AJDKdEIch7Dtj0/aC8iKR9Go= 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 11:48:49, Huan Yang wrote: [...] > Also, When the application enters the foreground, the startup speed > may be slower. Also trace show that here are a lot of block I/O. > (usually 1000+ IO count and 200+ms IO Time) We usually observe very > little block I/O caused by zram refault.(read: 1698.39MB/s, write: > 995.109MB/s), usually, it is faster than random disk reads.(read: > 48.1907MB/s write: 49.1654MB/s). This test by zram-perf and I change a > little to test UFS. > > Therefore, if the proactive reclamation encounters many file pages, > the application may become slow when it is opened. OK, this is an interesting information. From the above it seems that storage based IO refaults are order of magnitude more expensive than swap (zram in this case). That means that the memory reclaim should _in general_ prefer anonymous memory reclaim over refaulted page cache, right? Or is there any reason why "frozen" applications are any different in this case? Our traditional interface to control the anon vs. file balance has been swappiness. It is not the best interface and it has its flaws but have you experimented with the global swappiness to express that preference? What were your observations? Please note that the behavior might be really different with different kernel versions so I would really stress out that testing with the current Linus (or akpm) tree is necessary. Anyway, the more I think about that the more I am convinced that explicit anon/file extension for the memory.reclaim interface is just a wrong way to address a more fundamental underlying problem. That is, the default reclaim choice over anon vs file preference should consider the cost of the refaulting IO. This is more a property of the underlying storage than a global characteristic. In other words, say you have mutlitple storages, one that is a network based with a high latency and other that is a local fast SSD. Reclaiming a page backed by the slower storage is going to be more expensive to refault than the one backed by the fast storage. So even page cache pages are not really all the same. It is quite likely that a IO cost aspect is not really easy to integrate into the memory reclaim but it seems to me this is a better way to focus on for a better long term solution. Our existing refaulting infrastructure should help in that respect. Also MGLRU could fit for that purpose better than the traditional LRU based reclaim as the higher generations could be used for more more expensive pages. -- Michal Hocko SUSE Labs