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 A5796C47071 for ; Wed, 15 Nov 2023 02:12:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE7F06B02EE; Tue, 14 Nov 2023 21:12:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E708A6B02F9; Tue, 14 Nov 2023 21:12:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC2C36B0320; Tue, 14 Nov 2023 21:12:17 -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 B3EA06B02EE for ; Tue, 14 Nov 2023 21:12:17 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 815CD120685 for ; Wed, 15 Nov 2023 02:12:17 +0000 (UTC) X-FDA: 81458563914.01.C939AC4 Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2127.outbound.protection.outlook.com [40.107.117.127]) by imf26.hostedemail.com (Postfix) with ESMTP id 2213414000E for ; Wed, 15 Nov 2023 02:12:13 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=vivo.com header.s=selector2 header.b=Eyagvo7h; spf=pass (imf26.hostedemail.com: domain of link@vivo.com designates 40.107.117.127 as permitted sender) smtp.mailfrom=link@vivo.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=quarantine) header.from=vivo.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1700014334; a=rsa-sha256; cv=pass; b=lccPQ35rCQ1cVLN9x0GVUsPlrYTT2J8q7YRlQLZaEhjL1yb71sKv34ZDdXnWsdqVtSlkbo 5yfPLcG1347TY19xOx+uugVpypowjy4QDCLhrOXQTr8fBFde9IXq8JUevA8qY+6n4RGF// KoLkCjKpZeh463jWhnYAb1sXzlgqW8s= ARC-Authentication-Results: i=2; imf26.hostedemail.com; dkim=pass header.d=vivo.com header.s=selector2 header.b=Eyagvo7h; spf=pass (imf26.hostedemail.com: domain of link@vivo.com designates 40.107.117.127 as permitted sender) smtp.mailfrom=link@vivo.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=quarantine) header.from=vivo.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700014334; 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=oU6JtVK/yCuO8qPAYIFbuvPS/6Bo0WBkN67f8QH8OHg=; b=SzSbVsQM3cFu8Xl+Wmm3xU0dgAqa7yN2zeeKIbJpEBn10XWJqa3wp2hkyA5xi0mp5/IIIQ WehNJlNkVm183gCyHPm5fXjdo+t/cbRjp4DMUyJFxKOtI35QvrpVr48JvjHKnmGvI5Jq/d 85yJl7DD9gZLiTbHn59fSzaM3g9sunI= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RRr9Ei3nV5Mve16BLjlRicQVWeXxNbkMBsePrcIpY5qBfF2+b+z3bZZQPvOtZQW5hj4W3dTN7BC/vzj7z06T+2xozQf+X3gJggt3RFxtUpLUrS4/sQsAB4o+IEKYl5fB0gnEJ2m7GpqOuMgLNpZfuJY18Kc6aYgFkiTYruPar1Y7rw053YP69JcvaRP6NY1BN3xDhEnbbgqQWN8GTTdXW/PgY5eh40idaADJYin9bZFzcLnerTQa9HVQWcI7kWltmnd1dEzP+gaGAZ13o2wa2Fo4QMJjLMLvnS5IjljfGnvaSKXyvYmWXWgLOQC0E9UBWer8YBdvo6p8JRW7ya1PZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oU6JtVK/yCuO8qPAYIFbuvPS/6Bo0WBkN67f8QH8OHg=; b=lfMN4p0bIx3Y5BDiPp6aHl2nlPMaqnK5AzbvcE3XdPkcdO8h6P4BbSSTtBDDeMpDPQYyJmc7p0IE9jjZB7XHgO0rXAswSZW3WIn6n/WiezIP6p86ojNBKhTZA9rLG7b0NWRiKJ+sVDXo/P7PnU/VJmTe6/NmskrZlo79RbFU8rCe+BhPGIBstGT6yxRQ7+nnZSmQxt61cNmAR8bufjPF3uTEQ1+fBCK0orYZDPfU+IKIuFiWhwXfonOpEAUH8rR/58n7UAA5spJh8r5kuMWHFHzlalFN5GmocVa778RBxUZQfNa0hKJQh5vRecVaeuDxuZvKG7InQ5ilwnB3oba5+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com; dkim=pass header.d=vivo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oU6JtVK/yCuO8qPAYIFbuvPS/6Bo0WBkN67f8QH8OHg=; b=Eyagvo7hwkYppY/JzzjEOSf24TpDduCuiXU3Pq73q78QvGseqFLmoi9fm/b9cX+g642hY48xF9tvDQB4M52+3dWtb3+j+z967LJ6UgmYYoJj1p9O66NULSMr+9IXqevo3wTAWwStNHuDfrwg65SHkf+b+mWclmj+9GomxLg3+EK1LIFTPKfhuuoSb2JKSZO7fxUL5Cjjsq5W93EU4BMUEKatnfEtJGAyc8nb+oGp2Kl0MrOLtdLkA01KKIa1vlZ5eLuZE7dS7AAK1Dkgy1qCFA/4Tdurt9XIVf5FeOIKacKYsngg0UGZXHJ5CHTYo0tRJerF7GgdiX9rJX7swwMZ6w== Received: from PUZPR06MB5676.apcprd06.prod.outlook.com (2603:1096:301:f8::10) by SEZPR06MB6199.apcprd06.prod.outlook.com (2603:1096:101:e8::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.37; Wed, 15 Nov 2023 02:12:05 +0000 Received: from PUZPR06MB5676.apcprd06.prod.outlook.com ([fe80::d754:7b3:dc4c:6b48]) by PUZPR06MB5676.apcprd06.prod.outlook.com ([fe80::d754:7b3:dc4c:6b48%7]) with mapi id 15.20.7002.015; Wed, 15 Nov 2023 02:12:04 +0000 Message-ID: <9c92ada7-e6b3-424b-b940-44048b723d87@vivo.com> Date: Wed, 15 Nov 2023 10:11:56 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim To: Michal Hocko 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 References: <87a5rmiewp.fsf@yhuang6-desk2.ccr.corp.intel.com> <878r76gsvz.fsf@yhuang6-desk2.ccr.corp.intel.com> <78128117-ce70-47ef-b7fd-10c772b1c933@vivo.com> From: Huan Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SG2PR04CA0179.apcprd04.prod.outlook.com (2603:1096:4:14::17) To PUZPR06MB5676.apcprd06.prod.outlook.com (2603:1096:301:f8::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PUZPR06MB5676:EE_|SEZPR06MB6199:EE_ X-MS-Office365-Filtering-Correlation-Id: 917f7796-9ef8-422c-4bb5-08dbe58042dc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: WWRMZM2VBoLCzUYXB36AF1UgRr5f0XFPoK6smcsK9UTWciegyS8Z3EXeZj0ZaCVg3KZMxT5S2eBT8b2c6C2nvF+W7h+v62exg9YZSkXcSnsThIXYnCkvgDqXTlsrJmKKlivSj0faRwkYEiy6Z4NV4MplgNBi8Lzlt3R27LzTYYqrArfQZ0ikzX50UM+Vw2HaEOBi/InkyrEdJIV/hgWGqrOuAjREImTFpTHUFHuai2OIuLRzdMnNiTNk67SwLBDgVFOB0sE5D+ht5dG2oD464aXfyG0hpYqNGIWVWlNP9w6GXbR9AsWZQR3XogR4rHG8jyV7N+qqT8yxNrextjdI990yKhPjDsPpBzpW34YSS5Gug6EVK2CMeA7AiJLG2M/en/AqUft4xiw7/4z2e6eDrYTxCsikOnDOG+anyqHz/A93rmOt6zdmion55fT9frz86KFqqx/TKGEtQdEpcBmDBKkhsaOM/JUyMOG3YPiVWGonLZMwrSm59NDAq6Uj+830VJx1DghI4DuQEt2YBmtHKPGtU6dgOyaCaEBHInC341biZ0i4cZnklAHY/jnWdzjDY2c3kMeigWq3SNpLh+72WvzXaLy4IPAY2zUPcf77329PsEwoQC/jHzlvSEXVSRPxHNGqDkrhwn3iMpFivOI4OgcOMeNcTuxOIOgPjinNswCUyt8Ns5j01/PdZ7wya0gRgkgZiKc9pY6SmE5Ew1hSL2IJ4OlQL+xqGf5MhWz8Y9Y= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PUZPR06MB5676.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(346002)(136003)(376002)(366004)(39860400002)(396003)(230173577357003)(230922051799003)(230273577357003)(186009)(64100799003)(1800799009)(451199024)(38350700005)(31686004)(66899024)(66476007)(66946007)(6916009)(54906003)(66556008)(31696002)(86362001)(38100700002)(36756003)(83380400001)(6512007)(107886003)(26005)(6666004)(2616005)(52116002)(41300700001)(2906002)(478600001)(6506007)(316002)(6486002)(7416002)(8676002)(5660300002)(4326008)(8936002)(43740500002)(45980500001);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N1I0VW55VXN3SWx4aHYxUHNNSFlrTnlPaGMyL3lYTkY5cXRxekJDZlVGMHZU?= =?utf-8?B?OGplNDU5bVVES2ZHNEN0cUpIQW5WR2EvOHdJS2tnMUthazBqOUZSelV6RkMr?= =?utf-8?B?ei92cHZiQmwrK240NkVTYkZIV1J4WC94YkVCQy84NmNJQWllNzBsc29SejRu?= =?utf-8?B?TUgwQWxxK0RGRUg2c0FpNUQ3OVlubnR0c3FKbTVKSnFtbURybWR0TTJnZVM1?= =?utf-8?B?TmhmL3RlMzJuVFE4b1BKOS9lQ0hBVVRYZzlLZmxGbUdXU2Y4cStIa3RnVnVj?= =?utf-8?B?SW5aa2RHVGlrS25aWjBWTzdITDN4S1ZQZzE0MW03QWIvK3NkVmpvbGVzcUF4?= =?utf-8?B?d1QvUDNKUjNEMDV1bGZWSG41dXBpRnl4eEFuUy93TGRmdGU3YTc4S2pRYys4?= =?utf-8?B?Tlp4Yk9VT2tBM1lJM2sxMHhiV1BoRlpRUXdjV1VKRWc4bjIxR0ZaRk8zMEZo?= =?utf-8?B?cFZ3VWtseDJjeTdvUDNsTkVPVzE1eldnTy9BQnhVVm1hUFFuV2dCanJQOVlJ?= =?utf-8?B?eFRFV2d4N0R1RCt3V0tiMjVhazVRRlFuY2x5a0hWM0s1WWQzcWdocGgvWU83?= =?utf-8?B?bGswMUgvbVRPUVlheENHaVRhdmE2dmhiTzNTRzNneDZaZ2hTK0t4bzVRT1Rk?= =?utf-8?B?T1NJWXNFSXRWUlhRUk5MR3pqdTBBSjI3dzlzRUhacDk4aytpOUROYjBEQW9Q?= =?utf-8?B?alNvbTNoSkNJa3hVZHV6QVVyVzYrZzVIMldFRjV5TVFzTHA3RGZ1MHl1Q1U5?= =?utf-8?B?UTl6SkUxckVmN0lQSGdiUTQ1VVJBMFBxV2N4cnkrU1FsL1h5QUtqazUxd0xI?= =?utf-8?B?dmdya0VaQTNBQ1FxU2xWejJudlp0bkN3OUNyYUJmRGFvdU92U2g4eitQaFZO?= =?utf-8?B?cWU3L2N3UlJxdkdyY0psUFdxSTZyNjZoUW83aE1ZcEMzU2FnY0kyR1pxQmg2?= =?utf-8?B?aU0xdnNJU2ZIM1IvSE9lWXdhNm1ZR2k1RkgwQ3gzWGNtVU5NQy9rWnFoQXdF?= =?utf-8?B?SVNBZ3hBQkpMVGRuVk84bUQzQjdiSWNVd1o1RFlDMzkvWnowMnEwMThSaVht?= =?utf-8?B?M0plVnducHNNTktLYkYzdEsxN3QrTDBVNXVzdHZ5RlJCMitsOXlxV1pJYllo?= =?utf-8?B?akpJTkZXQXZ2RXhPWk5GY0NrVWdxQjZycFdGMFVZQUMxSkQ3UHByRitHY243?= =?utf-8?B?VkxkZEc4bUpRY2JvTE9LUHNwWks3bGFRc2syY0ZlZHRnN296VURFZ3pSQ2lm?= =?utf-8?B?MkVJV05pNUR5V0tKclFMeXZSeVhtNHNCVXQwdXcvbk5mR081Z2pBUklOZzlP?= =?utf-8?B?WitpRUVUcEhBZjdLa01xZnRDVUVzNWlyQzJaYkVTRmxWVmsxSUNNR3FJYkRa?= =?utf-8?B?Ty9Oc2hERVpEbU9qcVhRbEZIWEFkdzlMZ0xXTkpyNkJWbjhrdmZaUXd0S1Er?= =?utf-8?B?Q2xuVE9wOG4rdExnSHFYd2h0ZUl3ZmhvdEg4VCsrdVI3R29hRXMyZlVNS0pm?= =?utf-8?B?cHBWaHg0YjhjUUF6aGVXY3UyMTRqOVIxSElUeTNOdStsNktwMnNBa3Zhbm1Q?= =?utf-8?B?eVJkbmJVei92MGd4amo0Y2tmZlQ2YW5mdUo5a0YxUGEwRVNEbzF1VXZjRzQ4?= =?utf-8?B?N3dMZTJIQnQwUHdDVVpJOHpuMW1SOWZEZzZ0ckZpVDVUQ3Y3SHlMV24yeTVQ?= =?utf-8?B?TlhpMm9uMEdJVE1mNnpzU0hvclZQZWxoTUdtV3E4Zm9lN3ZxZTBlM3FRLzNO?= =?utf-8?B?TnhUNlduZ0ptK3UzMGt0ZTZHK09iUUhhdS9sK0RVYVlzSHBYOHQ0dldYQnRi?= =?utf-8?B?VkJjRUp4QVZqOGY2L3IyczhyTm8zTXRyOS91TXhHNmU2MG1xS05VM3BZM3Za?= =?utf-8?B?QktVZ0JITXNXSmg2VUFHc3p3eWIyTmFNcWZCVHprRENPNm9zMTBOb0pSZmov?= =?utf-8?B?N2xjU2oyZUZCc3g1SnE2R1dUYmR4Q0RFT2p4Sjhmc3kwaGYwOGk1czMzeDlz?= =?utf-8?B?MG9sTGkranBLUHArU1hIVG1TRjB1LzIyblpxRVZ0UGxmUTFMTHJiSHgvbXVy?= =?utf-8?B?KzRXUCs4UCtRdnNTdmJhOFFYVnAxdFZvUXI5NTNXcGcyZTRld2pVaGRXTjJS?= =?utf-8?Q?1Ui3abe1W9Sl59jt03E7GEOwB?= X-OriginatorOrg: vivo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 917f7796-9ef8-422c-4bb5-08dbe58042dc X-MS-Exchange-CrossTenant-AuthSource: PUZPR06MB5676.apcprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2023 02:12:04.6451 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: s6DabIfTAOzO/kDRgBkz/pStXljCybbcnsJ9R5OMAAwktxA8RQyCPeQXiuRl3Isiqg2qeickpyNNuAoF+dziWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZPR06MB6199 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2213414000E X-Stat-Signature: xxhqcy8ckjwpe5idugdb9y63odkgrcpu X-Rspam-User: X-HE-Tag: 1700014333-517628 X-HE-Meta: U2FsdGVkX18WjoZomjgelfKjTnFbu2pQll9yJJD5MYgpORoP4tPYiP4dKaz0rMM9WZfOCJ9jR9S1SE6EBwv9elsGUQaxDmZO3QD+RGAWTzcz81CjlznV+I6MnjELKqCM0z/rOzkPleSUMgbRY1uXrDvME0AJDkeJHH6FoseDzbkJWntyne42DxqYMb3N15S+dfy5rPqBHkprmbWbtlPkm0YjeBV9fpkKdSsywRVAztSgUn1g+Omf0VTDlPf0BuG0M6MCYnBIcqdi938gubdryrTfEu31G+ho3a17QeUQT2swelZN4se/NYA+L4/Lcg5VW3qgnJ59P51lBdXfnC7HG0RWF52xt7VFfOyObLKfubU26yIgpnM7OgaWK7/aZFwf9OWw/6dGCabep0oCv9WtBxC6rZV9fRnpDsAOhLM4Hp/CcZknSH0YGoYlCBzpYqDKpCzyJSWhwkKJEHLNkUAsuQ5Th+KsjFj1WuGRwxJyfkRQkaHDKY9v9lGNRHjyE67FJ7yzQf0VuM2F/wZYNyW54KYoFP3EVkUXcoLA7ArNbXo2+IoVCZ4u2mrp5/AGuE70kTmyokpLfoz8W9SD5j0UFw+FJtXqNCTAiNESIiJz6aBCnZwedaewL0ZkiSQYXVhmzDFeyC0B+NRM6Jo3jWl21Whk/N4hXqCYgfY4gmdnyBfjAhydBGCFEUYuVL62BwsRaTfn6s7AQW36St0D9k91CcDvY9rvdbcgoOfwb6WBBeMPHUDCM36FNYaIdVqu0aB7q+/n0wAtEKEUXJOgp8WJPHmHjXCA+ozBuokcmoti3fszPsR7sCpwiKqM2hOmBKE0cTeV4jdd9RFU5N6KGXKgefrc7DMsOCwOco12OpVa7acf6neXxDc/VGVHzmbPBYvH4UIPwuGBSYtwBJ6mewTBxOrGM+YMNUp/MimIjWqeD1bHKEgBqXhx624fumCaByk67sci52LJraAfWIn0r8D Wct5my9I Owt6x9tq1J2IcDcSU6J+0Si3TAV1F2CxrpkRH/YuRDpSXgGsr/j7kWOd+bN1O95LK2Zn6MEaSH3MJKvLy/KKIxaAwSffGsqHQzvpYj99CsayA7ochAfDo9o+Bf57MC0FAS7A3SKLIpvmTAXsP2oYhuam+dRM1bAF1PSrmb6pdZWOtBlhBfBpw3jw9nkqEjipz4ymcwC6SFWgVla17MT2WC9MOo8YJWgFyB/l7jJKLLjiw8vUarH3tE1rsWZZlnSuvnYqRCISnGMamernFYdk2dBB5rCZ8tKlfSG7I8zhA5z1atPqen9NyhL7fqtvxHRrDivAKyrwbmVAOFk5vGLlQiEG9bVmBfBo+29Rap0Z2EXGu18W248BH7TAFWQUPBtGcUpWqKG7i/6NCfoVRa/zSYSkyMQ== 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: 在 2023/11/14 21:03, Michal Hocko 写道: > On Tue 14-11-23 20:37:07, Huan Yang wrote: >> 在 2023/11/14 18:04, Michal Hocko 写道: >>> On Mon 13-11-23 09:54:55, Huan Yang wrote: >>>> 在 2023/11/10 20:32, Michal Hocko 写道: >>>>> On Fri 10-11-23 14:21:17, Huan Yang wrote: >>>>> [...] >>>>>>> BTW: how do you know the number of pages to be reclaimed proactively in >>>>>>> memcg proactive reclaiming based solution? >>>>>> One point here is that we are not sure how long the frozen application >>>>>> will be opened, it could be 10 minutes, an hour, or even days. So we >>>>>> need to predict and try, gradually reclaim anonymous pages in >>>>>> proportion, preferably based on the LRU algorithm. For example, if >>>>>> the application has been frozen for 10 minutes, reclaim 5% of >>>>>> anonymous pages; 30min:25%anon, 1hour:75%, 1day:100%. It is even more >>>>>> complicated as it requires adding a mechanism for predicting failure >>>>>> penalties. >>>>> Why would make your reclaiming decisions based on time rather than the >>>>> actual memory demand? I can see how a pro-active reclaim could make a >>>>> head room for an unexpected memory pressure but applying more pressure >>>>> just because of inactivity sound rather dubious to me TBH. Why cannot >>>>> you simply wait for the external memory pressure (e.g. from kswapd) to >>>>> deal with that based on the demand? >>>> Because the current kswapd and direct memory reclamation are a passive >>>> memory reclamation based on the watermark, and in the event of triggering >>>> these reclamation scenarios, the smoothness of the phone application cannot >>>> be guaranteed. >>> OK, so you are worried about latencies on spike memory usage. >>> >>>> (We often observe that when the above reclamation is triggered, there >>>> is a delay in the application startup, usually accompanied by block >>>> I/O, and some concurrency issues caused by lock design.) >>> Does that mean you do not have enough head room for kswapd to keep with >> Yes, but if set high watermark a little high, the power consumption >> will be very high. We usually observe that kswapd will run >> frequently. Even if we have set a low kswapd water level, kswapd CPU >> usage can still be high in some extreme scenarios.(For example, when >> starting a large application that needs to acquire a large amount of >> memory in a short period of time.)However, we will not discuss it in >> detail here, the reasons are quite complex, and we have not yet sorted >> out a complete understanding of them. > This is definitely worth investigating further before resorting to > proposing a new interface. If the kswapd consumes CPU cycles > unproductively then we should look into why. Yes, this is my current research objective. > > If there is a big peak memory demand then that surely requires CPU > capacity for the memory reclaim. The work has to be done, whether that > is in kswapd or the pro-active reclaimer context. I can imagine the > latter one could be invoked with a better timing in mind but that is not > a trivial thing to do. There are examples where this could be driven by > PSI feedback loop but from what you have mention earlier you are doing a > idle time based reclaim. Anyway, this is mostly a tuning related > discussion. I wanted to learn more about what you are trying to achieve > and so far it seems to me you are trying to workaround some issues and > a) we would like to learn about those issues and b) a new interface is > unlikely a good fit to paper over a suboptimal behavior. Our current research goal is to find a possible dynamic balance between the time consumption of passive memory reclamation and the application death caused by active process killing. The current strategy is to use proactive memory reclamation to intervene in this process. As mentioned earlier, by actively reclaiming anonymous pages that are deemed safe to reclaim, we can increase the currently available memory, avoid lag when starting new applications, and prevent the death of resident applications. Through the previous discussions, it seems that we have reached a consensus that although the active memory reclamation interface can achieve this goal, it is not the best approach. Using MADV can both use existing methods to achieve this goal and decide whether to reclaim based on the characteristics of the anon vma, especially the anon_vma name set. Therefore, I will also push for internal research on this approach. > >>> This would suggest that MADV_PAGEOUT is really what you are looking >>> for. >> Yes, I agree, especially to avoid reclaiming shared anonymous pages. >> >> However, I did some shallow research and found that MADV_PAGEOUT does >> not reclaim pages with mapcount != 1. Our applications are usually >> composed of multiple processes, and some anonymous pages are shared >> among them. When the application is frozen, the memory that is only >> shared among the processes within the application should be released, >> but MADV_PAGEOUT seems not to be suitable for this scenario?(If I >> misunderstood anything, please correct me.) > Hmm, OK it seems that we are hitting some terminology problems. The > discussion was about private memory so far (essentially MAP_PRIVATE) > now you are talking about a shared anonymous memory. That would imply > shmem and that is indeed not supported by MADV_PAGEOUT. The reason for > that is that this poses a security risk for time based attacks. I can > imagine, though, that we could extend the behavior to support shared > mappings if they do not cross a security boundary (e.g. mapped by the > same user). This would require some analysis though. OK, thanks. I have communicated with our internal team and found out that this part of the memory usage will not be particularly large. > >> In addition, I still have doubts that this approach will consume a lot >> of strategy resources, but it is worth studying. >>> If you really aim at compressing a specific type of memory then >>> tweking reclaim to achieve that sounds like a shortcut because >>> madvise based solution is more involved. But that is not a solid >>> justification for adding a new interface. >> Yes, but this RFC is just adding an additional configuration option to >> the proactive reclaim interface. And in the reclaim path, prioritize >> processing these requests with reclaim tendencies. However, using >> `unlikely` judgment should not have much impact. > Just adding an adding configuration option means user interface contract > that needs to be maintained for ever. Our future reclaim algorithm migh > change (and in fact it has already changed quite a bit with MGLRU) and > explicit request for LRU type specific reclaim might not even have any > sense. See that point? Yes, I get it.  This also means that if the reclaim algorithm changes, the current implementation of tendencies will need to be modified accordingly, which requires a certain cost to maintain. If the current implementation of tendencies cannot prove its necessity, it should be keep deep research. This solution may be simpler for me to achieve our internal goals, but it may not be the best solution.So, MADV_PAGEOUT is worth to research. This conversation was very beneficial for me. Thank you all very much. > -- Thanks, Huan Yang