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 324B3C4167D for ; Thu, 9 Nov 2023 12:46:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 908038D00E4; Thu, 9 Nov 2023 07:46:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B8FA8D0073; Thu, 9 Nov 2023 07:46:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7800C8D00E4; Thu, 9 Nov 2023 07:46:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6A9DB8D0073 for ; Thu, 9 Nov 2023 07:46:03 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EF67640355 for ; Thu, 9 Nov 2023 12:46:02 +0000 (UTC) X-FDA: 81438388164.18.ED5F5A5 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf13.hostedemail.com (Postfix) with ESMTP id 025292001B for ; Thu, 9 Nov 2023 12:45:59 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="E7t/vPPR"; spf=pass (imf13.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=1699533961; a=rsa-sha256; cv=none; b=SSL9R/gSsUPEUTt1oGlghZWFAhsW7AWxeV1M0EDLdFyH2nD5V/xSybeeVDGsRHOibii9FC moYcRM+ayoQcjYZMExjj5dEWGhieLVNIe9qjHv2yyLXe3xF5Sjgps0VHwr6LltPkhhOhNs dd6p6SCnTNBTske1A30l6N5M99wIOzM= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="E7t/vPPR"; spf=pass (imf13.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=1699533961; 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=HXBYSsMM7dNCINQinGuxS5CHJRB8whseQnR30IMhhnw=; b=18GsR1gtVuts+qouUCZRzOHLHcou62pZh4BXpd2bsFYzapLHg3VEdx+q8FlIoB2IJaNQtT ndEm0f+rzXtNau8bBCDBlAQJEtoImRm7gn7S76tmyWhP6Z4saIfhi8VfkT/UJ2e0LF0jVR R6wJc/CrSSu2SaDIbJFOhlgFyKRa1Tg= 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 3B72521977; Thu, 9 Nov 2023 12:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1699533958; h=from:from:reply-to: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; bh=HXBYSsMM7dNCINQinGuxS5CHJRB8whseQnR30IMhhnw=; b=E7t/vPPRub+eIl262tzN7R6DYYa5adyHslyO4SnBBHWCvgs/u4Yv6naj2zbRUDhRpESqpL yT554ZVm2uY8YacmJIIxlFIBLCIeiBKJBOkHSQ9k98nHsJ/QrTlgwddzOs3Rn2Nq5ZKr1M skoOCwSO7iWgcP1MBa6UCo0xeVjstUY= 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 22CB413524; Thu, 9 Nov 2023 12:45:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id o5bfB4bUTGXfOwAAMHmgww (envelope-from ); Thu, 09 Nov 2023 12:45:58 +0000 Date: Thu, 9 Nov 2023 13:45:57 +0100 From: Michal Hocko To: Huan Yang Cc: Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Huang Ying , 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: <20231108065818.19932-1-link@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 025292001B X-Stat-Signature: oc6hodf6p3qongp4n3j9mtjmh86fgprb X-Rspam-User: X-HE-Tag: 1699533959-640125 X-HE-Meta: U2FsdGVkX18W7My/dgV690dS3g9GWRLFcFLYuYAXZtloyVRmLgNCp7XtYbmxNsXqSeoZEFhysiUo9ACvb9NlX13T9hUa2Ic2kQqzCuIeCh1cOal5W8jKFujYIaEsW4ptdsm52pAW9Hmzq47MBnW6QbS6dtxib+uZfI0viP5KZmpPYETyxqDhOZG1WBUlnJfVk8vlt+lrB38RONmffOAuTAv/ULRwKWZraCuq5WMeZFHvDadNNULyH1wkV9tyAihZMVFChXRbDsNE7GtDyP9uYbrKrE4l4Ftk/g8JRiXKe2sC6jt1oCsE/REFm4aNegMZdWrvu5J+jQheWuBCKQFs9zsMt7kDCiZVBkF4AZX5Fcqqhjsyop1vVfatSmLMgnrzDt5EVj+lArgRDQeIy29xZwIC/xE1pnnw2B5sQ018WgGAQngobp3MlRwdflua5s8e3ooVKjl0l1QCWRBjGjUpn3UkruEi7HJQckK0LTs+2JCzteaL2f60dyuuwWuKLILCpUJZ1++nsK2GWU0JH3D5w7l7SezxywvLNTj2OSSmLMLXgua59XeTvVEtTvh9LuaW99/e+KshhFyOSYyWpSRNjXiGXNfUi/qNDBcG+22AX+IorlU2NWTURbpPHrXn1HF8PcYSvkBnCtaUXnsc3Iy2W1drH3ySJzUdHnX+6whvtxCPAzK2QQ+RFdJjnrsPxkRfgHMIO3Lvsdw85sX5EHSdcB5RRjtNRn7sn2S7pKRo8wgABmGl/vatTryab5sn4W3vThukqX9PG5ZnL4hHcYrhY83agtJU1k4Jg0gBx2FIjQzW56j2+J4qkipzeIZzq0+aTx/Hlb8hcvc/XdhQ/i+y2YrJhcVQuU9emO5TL3MogQyWqF8tgWuCoyGt0NoMC5Bg9woyOQQrqKka2pNyUPkVR9YiIY/2G++dA+TuF5N4Y35Ha3GGi7GPdUwf4MX7REdirpwEmC9etOaAcKmHOS1 PS6YqREt ht39sbh0Ot+AT5iYd8thDplmFKHPVqfI8RfXy6TmZujv8++opQYqwrZH3uZkZgAps+yY9wriskIiCFol+8y0tgwub6JHaZDF1OE1QSX86CdpQ/LT4RW0F9c+P9OK7bAAmFWbPkJoaCXqkx9IKQQRzujPI+TxyvNan+CUXpUk+t5KEqKBp0myeVgMt8z56zB4v4cgztEeMuTjZjo2s4X+3PkdDpHUMB0HPaxKBqfoZenqwgSFWx7Zd7bV/zm7Pq/i1prg4vU6r16ow8Y/Hsloe5bh5/bYvn+bxH+ISqA/JT/ROyHwgq53sqsseeQL6Oe4DzzSI9h6aKdLVXqGhvGu7P4Nty/ukqgnabIJ5lb7LbaIhIVewIuFGnUJwWKVhgkH7XzajQlH2EpXlhj6cf7lbgU4SFQ== 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 Thu 09-11-23 18:55:09, Huan Yang wrote: > > 在 2023/11/9 17:53, Michal Hocko 写道: > > [Some people who received this message don't often get email from mhocko@suse.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > On Thu 09-11-23 09:56:46, Huan Yang wrote: > > > 在 2023/11/8 22:06, Michal Hocko 写道: > > > > [Some people who received this message don't often get email from mhocko@suse.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > > > > On Wed 08-11-23 14:58:11, Huan Yang wrote: > > > > > In some cases, we need to selectively reclaim file pages or anonymous > > > > > pages in an unbalanced manner. > > > > > > > > > > For example, when an application is pushed to the background and frozen, > > > > > it may not be opened for a long time, and we can safely reclaim the > > > > > application's anonymous pages, but we do not want to touch the file pages. > > > > Could you explain why? And also why do you need to swap out in that > > > > case? > > > When an application is frozen, it usually means that we predict that > > > it will not be used for a long time. In order to proactively save some > > > memory, our strategy will choose to compress the application's private > > > data into zram. And we will also select some of the cold application > > > data that we think is in zram and swap it out. > > > > > > The above operations assume that anonymous pages are private to the > > > application. After the application is frozen, compressing these pages > > > into zram can save memory to some extent without worrying about > > > frequent refaults. > > Why don't you rely on the default reclaim heuristics? In other words do > As I mentioned earlier, the madvise approach may not be suitable for my > needs. I was asking about default reclaim behavior not madvise here. > > you have any numbers showing that a selective reclaim results in a much > > In the mobile field, we have a core metric called application residency. As already pointed out in other reply, make sure you explain this so that we, who are not active in mobile field, can understand the metric, how it is affected by the tooling relying on this interface. > This mechanism can help us improve the application residency if we can > provide a good freeze detection and proactive reclamation policy. > > I can only provide specific data from our internal tests, and it may > be older data, and it tested using cgroup v1: > > In 12G ram phone, app residency improve from 29 to 38. cgroup v1 is in maintenance mode and new extension would need to pass even a higher feasibility test than v2 based interface. Also make sure that you are testing the current upstream kernel. Also let me stress out that you are proposing an extension to the user visible API and we will have to maintain that for ever. So make sure your justification is solid and understandable. -- Michal Hocko SUSE Labs