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 9A434C4167B for ; Mon, 13 Nov 2023 06:12:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 18CB68D0021; Mon, 13 Nov 2023 01:12:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 13CC88D0001; Mon, 13 Nov 2023 01:12:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 003738D0021; Mon, 13 Nov 2023 01:12:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E686E8D0001 for ; Mon, 13 Nov 2023 01:12:13 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B7897120512 for ; Mon, 13 Nov 2023 06:12:13 +0000 (UTC) X-FDA: 81451910946.30.C64C553 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf05.hostedemail.com (Postfix) with ESMTP id 313C110000C for ; Mon, 13 Nov 2023 06:12:09 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IhYwsCKk; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699855931; a=rsa-sha256; cv=none; b=X4hGBu1qjTjv0trMHoFmRisLgUG/UA1KUGVlCWBuk5xCKTNcFrqApv7ARCIyH7bAbcEUap pMzKNzfoaITCY54LqEGape9bHv581mrrEvkXwx+kJMwmersGyP3NmqELX8iR5eoS8sxUEx Q0Zp5rHOOBohTHWrYHvESzvmRsZSvgo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IhYwsCKk; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699855931; 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=MGQ068ad/O+unvO+62yJD37KYsy1p5Znjy55WsKkWNU=; b=3DrHkD3htFR8vY9iLmNvGt7qRnsqqhAXAf4VJjG9MBLPGsx2Oiy7eg1GLelEoUqYvMsXWh b4Oz3wUSQRDjUD6By1NY5hzGa95i68IKM/dW7gK6JWanV/0eLHJ4lYt4eIsEDL75Hm485S YKMUz3yUjYdWeTdr06bBQMOUQQLcDt8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699855931; x=1731391931; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=7LcmL3v83gLciivg6YlvQU94smXGBtfXXsaeFuMWyIw=; b=IhYwsCKkeX9AiNklFtFNh+I1CTsrh9W8AZkY9MB6APMQaCE1aHAnroZw P/YYISDAFQoxyRtCrhiQxPzIHlAvt5Whqp1fJ7hIUV9cECcqNDyfKkzPO FH5/CBVthbkqw2CM7NmN1VYWn4bM6x8lV+e9vUOn6rlG5dCt1sj+COh+/ lybTwebh5rvBEGHDiatjbz8IFb6x46dtbapbl9HmknzDYSetGfoZkjjVo eD8hdAcgoLupbNtp/OvIGysEPB97An9nmn3kQyC3PJ/cD+k41VgnqHg0U jzGbtVxlXQuDGk1c+PSef+m31153KZw+lNeM/k1ALfUhuj3+YxMEJkNFE A==; X-IronPort-AV: E=McAfee;i="6600,9927,10892"; a="9027771" X-IronPort-AV: E=Sophos;i="6.03,298,1694761200"; d="scan'208";a="9027771" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Nov 2023 22:12:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10892"; a="887846916" X-IronPort-AV: E=Sophos;i="6.03,298,1694761200"; d="scan'208";a="887846916" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Nov 2023 22:12:02 -0800 From: "Huang, Ying" To: Huan Yang Cc: Michal Hocko , 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 , , , , , Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim In-Reply-To: (Huan Yang's message of "Mon, 13 Nov 2023 10:17:57 +0800") References: <87msvniplj.fsf@yhuang6-desk2.ccr.corp.intel.com> <1e699ff2-0841-490b-a8e7-bb87170d5604@vivo.com> <6b539e16-c835-49ff-9fae-a65960567657@vivo.com> Date: Mon, 13 Nov 2023 14:10:01 +0800 Message-ID: <87edgufakm.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 313C110000C X-Stat-Signature: sk69ftfwzyzmd1h4zekbhhf935swb73c X-HE-Tag: 1699855929-773549 X-HE-Meta: U2FsdGVkX1/snpEpzXxg6XW2gwbC5DgQsxT8tjhcQIhkHWO1/acfCd+Z4Wb26xxW8MBhOgWD8nMQGe8eSXlgcEH6uDNL06oh77D9JWl4DV9FDeowncYGFRv7MnYiTli68lW0B4ZXx5hsCfRn1j3PnUASeGQ7xBc2dnLj2RQb2N3To3vYFqStYOaUkqAfopmC1cYls/fmtDSotD8MSTD9NBRbB5IaPvwCrrpmDKplbGJn5jGKJ1V7Qc8hS142v4at+m8P7qic4nIcaWND8xSLvZHJUI1MCqRhuDDbtCkSFgMrERHAB+1HbNktFyGJ4/vUc5MkbIRj7Px1FbtOBK33Exc7v2Sk72NTgZLS6FMaVsAqikyPN1Bb/Tf1hApQLw5wYfIZumrDGCOOoRL5n9Sb9KwnnT+kic9VXwsfFcRX3xditCBRN4P4h8RW+d7pav4ctquomvU9Vy6bTfdNP8ANxWgiyb/0sTGdLYcp1m71/a564K1z35kBC+KQZ9+VSqrGgqT7PEGt3HaEC5Ti3tu1BHbG9aue3hd1TZpb8IskR6uFVxHkqICusX570zejybZJsHD+hZABGLezqUjEjMdUZPXI0pTwXNQYdamq0tO9KGKkJPk+1XRwA/W78/hdOnkl/BmPCy6WYvpekjjhOOA55kqGwmd6t1DEKz8G92FwXuU5GqT7ZNQN3/B0I55Y0mKUHeFxd0ZGRppbG6KqdHaG7OTLbgHf4M16JGdleBG8Y522DYAaVgJdsUxTgilX1M5ZKbamZMyO9CRckhcSyNDAKisyaQUYg7N8pos+mmu65gbGPDL7z/PCWUPsum1NifUevy5UadJXTcz1sEcCQIpecYFmXb49TW6GA6bVK7rtb5uHYtGOsXJR/i3VVrM56rE3SYTgdlC67Cls6ydZ2K3ndi8GRa5/ngojn4bmIPv9HUDoLrFaRAH/ao+l6CxVie2Ou6AlTn8+lho3PAPHdi/ r34s6Qnm VKv/enmUyVtWL/M9bmlYtY6/rsdc3u4E/4dV3VTUdmY+cqL9TskexBNT0g8TKLEiwqGJtxol+ItJ7cZDyD42uM0Ct7LUIZVi1xwLStrt0wJvBD1ablViWEuHjWA2ud2qaKV/42Sx/r+ST+svIcgY7ApGoi9Zn2OGZE5UivM7PlSWnAMDzpkgh3WGqJEm0nrE1qOQIDhVdOv6VV4GNprXDnjjwcl584jUAUs7HyMS33EvrEU0= 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: Huan Yang writes: > =E5=9C=A8 2023/11/10 20:24, Michal Hocko =E5=86=99=E9=81=93: >> 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? > Frozen applications mean that the application process is no longer active, > so once its private anonymous page data is swapped out, the anonymous > pages will not be refaulted until the application becomes active again. > > On the contrary, page caches are usually shared. Even if the > application that > first read the file is no longer active, other processes may still > read the file. > Therefore, it is not reasonable to use the proactive reclamation > interface to > reclaim=C2=A0page caches without considering memory pressure. No. Not all page caches are shared. For example, the page caches used for use-once streaming IO. And, they should be reclaimed firstly. So, your solution may work good for your specific use cases, but it's not a general solution. Per my understanding, you want to reclaim only private pages to avoid impact the performance of other applications. Privately mapped anonymous pages is easy to be identified (And I suggest that you can find a way to avoid reclaim shared mapped anonymous pages). There's some heuristics to identify use-once page caches in reclaiming code. Why doesn't it work for your situation? [snip] -- Best Regards, Huang, Ying