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 41901C4332F for ; Fri, 10 Nov 2023 01:21:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4AF028000F; Thu, 9 Nov 2023 20:21:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FB2328000E; Thu, 9 Nov 2023 20:21:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89BDD28000F; Thu, 9 Nov 2023 20:21:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 794B028000E for ; Thu, 9 Nov 2023 20:21:14 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4A2BBA0CF6 for ; Fri, 10 Nov 2023 01:21:14 +0000 (UTC) X-FDA: 81440291268.05.3DB4763 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by imf16.hostedemail.com (Postfix) with ESMTP id A9CF2180008 for ; Fri, 10 Nov 2023 01:21:11 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VGivKTIf; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699579272; 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=cJrFxYnnzOqQU2MR6h792iNlaQudWPaZpAv20pys74M=; b=iyPz+PBuaJtVq/SOX/XEPcimK2aAIKeYj4mKbsArx3VXEu5TRDRjJbWNh2pKKLTdaNCp89 SISXm7pKhsUShz5vIuNRksSaocZ4gg/UznxuhlOYdOhnMFMwjYRLb7BZ1gPoC7mdiXnTo+ OAUGv0/bpP/3aDE2y5EHKaGeQlAWZfU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699579272; a=rsa-sha256; cv=none; b=WGNf9C1VFvllE0aML1jKNcpc9VR2fR1ms8FAixQAS7NC/wvbhaPTte80pZcgDHwvRXid8N 1tKOdTMYK0gWYt/vPCLnqiajYWH1VjxDk62AuZyq4RKxl9MWXRkv/ohzNfOIjjq9mHjQtK i2Xu2BF7EmG9KMJpG3DgJsVZGkUR8pI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VGivKTIf; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699579271; x=1731115271; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=oSLgzdqqUi7SDhMmhRVGvgJyNjx+NqyiNkbZfvYhL7w=; b=VGivKTIfQEcVxvThi5BD+JgG/2Q+RPjHGZ6ioiUPuqRpOhtjnyOxVwMn N1Qoax2k/cVPqODT5Y4JAsoBikpPtFQbDRC86D6oQDez7Oe+3jz9mJ/Zl UKLeOtHQaG4708wabMzkwEaWm2ME3M/gb8ubB2CVqTLLYWtuJ0uLM2nkl wqznNPnip6tC02EziNQyaYNJ5/hG66r0YxKWdGb6x5GTti7GMwciXCJFN dNBpJKAWFipwF4iGONaD32psqwcYinaFwx0Vkd+0EsAlmW26gJySU14AR KUt+9Q3o31/8cGbaNqKtCT3mp2M8B+nLGj981uXpTkhqHheSrsTIajbqb g==; X-IronPort-AV: E=McAfee;i="6600,9927,10889"; a="476339547" X-IronPort-AV: E=Sophos;i="6.03,291,1694761200"; d="scan'208";a="476339547" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2023 17:21:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10889"; a="763611091" X-IronPort-AV: E=Sophos;i="6.03,291,1694761200"; d="scan'208";a="763611091" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Nov 2023 17:21:03 -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 "Thu, 9 Nov 2023 18:50:36 +0800") References: <20231108065818.19932-1-link@vivo.com> <87msvniplj.fsf@yhuang6-desk2.ccr.corp.intel.com> <1e699ff2-0841-490b-a8e7-bb87170d5604@vivo.com> <6b539e16-c835-49ff-9fae-a65960567657@vivo.com> Date: Fri, 10 Nov 2023 09:19:02 +0800 Message-ID: <87a5rmiewp.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-Rspamd-Queue-Id: A9CF2180008 X-Rspam-User: X-Stat-Signature: pspfb3r4zd5hhd5cicihksp3w5h34mcu X-Rspamd-Server: rspam03 X-HE-Tag: 1699579271-337963 X-HE-Meta: U2FsdGVkX19IoMC7gEBaOhdBe1vU5T3urWhspSxtyM2R8YOgAjQYz9Eam2khsezVCi0WAoaFvnHsjzcDqcq5SYGiC7ADr5zce/7watJ7GDPJN4ib0CNpCFwo6RJMhb7jYPneLUDw+bcn/hD1C+1g6Ab75hou6DO/Zw+GNvzon+ukx/W2KJia6luFeJOWSwPfqbLB5YL8winiz+3gwCK+spV07dWP/V5hmnlzvETOnLRHUli3YtElcscZzXTwcTHcNJxmPj1ZpiU3htzUjS5ynMvrDzLCTolaMrSCN4iiTLnpyDtLOy0PMJhF+4VFibj6YNjSm2M0zOZ4RvTPr5eYg6wpaevoVOg2PtdXAoAshFLIzsYrI4OPoU8UsTeL3/Mbg7oikFzAIKtWt44D8jSlTF8+Zd99nrVwosz6ttMNKaQphtuRVeWTiPIulupTTX5PsvT1ya+kcHr00DQZ1FVNrcFRaZvZdMhrtBT8k3xUctFqvqe7aQ5TnHFLy0kVJUcxs7qAEEQpRK+I6pvPOeGtan4ON/6Wo8GuRKAiKALs2gGX7r42qDkmNrT6bv16FXX3Tj7cDAOBHXfXEgC5j1n+oevxYuFFhhFVEIfVxYntw6EhzzAyp6KV4HYG/ja3Y6z21El7syuPusZG0iudL4986F17fbmsw5+YwGr8KK7+OxaFhAgpRHD/m+phMxRL3oauuUXJ+VZTg5LokHkou2hTOAwX/Dx8jzqkcF18srsmy+EdAm2jjdUSC1RhgA61x39+FAHMumjzX7YNWwYqAcVL089l7Wf/zSzpKwx+f2CI3ETs+HsRuEcgzs4eCd7OfOk20CFoJqMXUlryESXFNp+tf+f0pyg7aT6u3fMYn1vv51TrADLEML/BE/e/D2lVbuYCUbAMbwJZuZAwNmqLypfZRnFihCuOBlp9vEHzfZ6R3X+ZhI83K124gZXclljmLsyQK1Dm7sHLIv/ckwoa8CN J+cdWF1D zXdLbmsuYS2K5FaWyvVDcX6eIKep87o/8JedkMQWcI9tZ9ovYHspRJ3kM5XGlJeWxIitz+AuSQkVOvkGVTokDpcnArJxhld2QILNu2LXvN8QAXVRmnSbI8yUyJmMG49Eq+CQc2wTvPy0IcCMsl90n2CrWyKh51UThbHVSsoy2KRM47ilmEZ3zy8etad9Tc8D59RjDvye6xNS1TorDH9tKQhztS3O76PMwFLrCkqjuup2x51D9+J+nvhrqqywveAtIYHDj4EmgbpU20oCa/UD954Tnsf0w2f2Kxi9sJVmLWty4jekQWSgVP2g2KL35pHJmDojO5g2ccAG3P8h0LsbB1nL83k/AQ09/yQoXGukSiZp6vx7NAPM6NCKvFoX3baDVm16uQsbsLVYIrqlglfrGT/UcI6g9nlnr3yVRsxg7P2RKMFc= 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/9 18:39, Michal Hocko =E5=86=99=E9=81=93: >> [Some people who received this message don't often get email from mhocko= @suse.com. Learn why this is important at https://aka.ms/LearnAboutSenderId= entification ] >> >> On Thu 09-11-23 18:29:03, Huan Yang wrote: >>> HI Michal Hocko, >>> >>> Thanks for your suggestion. >>> >>> =E5=9C=A8 2023/11/9 17:57, Michal Hocko =E5=86=99=E9=81=93: >>>> [Some people who received this message don't often get email from mhoc= ko@suse.com. Learn why this is important at https://aka.ms/LearnAboutSender= Identification ] >>>> >>>> On Thu 09-11-23 11:38:56, Huan Yang wrote: >>>> [...] >>>>>> If so, is it better only to reclaim private anonymous pages explicit= ly? >>>>> Yes, in practice, we only proactively compress anonymous pages and do= not >>>>> want to touch file pages. >>>> If that is the case and this is mostly application centric (which you >>>> seem to be suggesting) then why don't you use madvise(MADV_PAGEOUT) >>>> instead. >>> Madvise may not be applicable in this scenario.(IMO) >>> >>> This feature is aimed at a core goal, which is to compress the anonymous >>> pages >>> of frozen applications. >>> >>> How to detect that an application is frozen and determine which pages c= an be >>> safely reclaimed is the responsibility of the policy part. >>> >>> Setting madvise for an application is an active behavior, while the abo= ve >>> policy >>> is a passive approach.(If I misunderstood, please let me know if there = is a >>> better >>> way to set madvise.) >> You are proposing an extension to the pro-active reclaim interface so >> this is an active behavior pretty much by definition. So I am really not >> following you here. Your agent can simply scan the address space of the >> application it is going to "freeze" and call pidfd_madvise(MADV_PAGEOUT) >> on the private memory is that is really what you want/need. > There is a key point here. We want to use the grouping policy of memcg > to perform > proactive reclamation with certain tendencies. Your suggestion is to > reclaim memory > by scanning the task process space. However, in the mobile field, > memory is usually > viewed at the granularity of an APP. > > Therefore, after an APP is frozen, we hope to reclaim memory uniformly > according > to the pre-grouped APP processes. > > Of course, as you suggested, madvise can also achieve this, but > implementing it in > the agent may be more complex.(In terms of achieving the same goal, > using memcg > to group all the processes of an APP and perform proactive reclamation > is simpler > than using madvise and scanning multiple processes of an application > using an agent?) I still think that it's not too complex to use process_madvise() to do this. For each process of the application, the agent can read /proc/PID/maps to get all anonymous address ranges, then call process_madvise(MADV_PAGEOUT) to reclaim pages. This can even filter out shared anonymous pages. Does this work for you? -- Best Regards, Huang, Ying