From patchwork Tue Jul 2 08:44:03 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Huan Yang X-Patchwork-Id: 13719107 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 4DF2EC30658 for ; Tue, 2 Jul 2024 08:46:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7557F6B0082; Tue, 2 Jul 2024 04:46:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DE546B0085; Tue, 2 Jul 2024 04:46:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E2EF6B0088; Tue, 2 Jul 2024 04:46:09 -0400 (EDT) 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 278936B0082 for ; Tue, 2 Jul 2024 04:46:09 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B68ED161BB5 for ; Tue, 2 Jul 2024 08:46:08 +0000 (UTC) X-FDA: 82294180416.18.3E0CCA8 Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2050.outbound.protection.outlook.com [40.107.117.50]) by imf30.hostedemail.com (Postfix) with ESMTP id 49B1E80004 for ; Tue, 2 Jul 2024 08:46:04 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=vivo.com header.s=selector2 header.b=ROMGnPAC; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf30.hostedemail.com: domain of link@vivo.com designates 40.107.117.50 as permitted sender) smtp.mailfrom=link@vivo.com; 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=1719909943; 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: references:dkim-signature; bh=SXGrPsUSwM7UDTr+Xy8l8D/8QVX2s2rwHYeg+bJMefI=; b=WQ4bp1IltMFlKfkRFRqiEpDGE/BEvbH+gwuUHKZ6S2/mpKC4/yUnNuyWSd3t3E9iLUZBJ+ n6DoBn7EZJW9hlIYdr1azG675EXRH1wl6wYRPq2F9Ev+QB9deKgl+eIMiwZe0nnZvxbWGK hv+lnkFpwscQt09r0ppqnF8SFu9+dvY= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1719909943; a=rsa-sha256; cv=pass; b=nuAQFwzG4c9JnOZLf9t52wk6gpQdEZFkV8/dzwM7vs+g9tal8RZ9O8FQvJIQ9honJtlkgj 5ZRopcvcdKyHRjIur1v0n0Mi4tiJwc6dcZv9yihEly+XAYlP9axhKtHk7K8JJy/k0ueHcN +TUMDmbKY7BkSlVzD8P0QegasdSUpFA= ARC-Authentication-Results: i=2; imf30.hostedemail.com; dkim=pass header.d=vivo.com header.s=selector2 header.b=ROMGnPAC; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf30.hostedemail.com: domain of link@vivo.com designates 40.107.117.50 as permitted sender) smtp.mailfrom=link@vivo.com; dmarc=pass (policy=quarantine) header.from=vivo.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l0wble79eEfzY9YgM7XzmwlIj4eEs5OK7KmBhfElLNEt8qIsHF7zh+2VaQFmoLK9oPO5N3hsKWbFCTg+UNY/9AYpBPDSJufkmzG+XYbbzlY24HP9FNNh1OzYcxlR3oIEaDq5WeAiHduPSGBx7EkjuN8VfpQsHOi5sVKhHGK8lAIHw31w+OmUn7SDq3ntFX9lLqDXEu41IQcn7nQwEEHYXzJpi5FRYHWYccjqIvGUI3Fn3v8wv5tGSbNx8fetMwfEO0QuDRlSid8rfpcTV0oXcfjmgUec1GgMGCtzqhp20ILaOMvkEmdIAd1w1a44eyJgCundn9YV9LzCyRvxpO41sQ== 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=SXGrPsUSwM7UDTr+Xy8l8D/8QVX2s2rwHYeg+bJMefI=; b=Iw0DkotNBTdmBjizMAW3K8us3mDZxQ/muLr6J+3ZUBxwveGg9aHrFqf10ZP7ETznTM66T/Tv/O/Z8sJ/pKqurz2REXBD9h8aBhHZIv3pWBxB6h4AGb1J264WRAHO3wjjP3vGKQxYi2zoAyCatSPTfthngIoNuyqO7TnCfOlpHpzBa+s+FWk6RcXm9OHrJ2jBw2aza954xtFxR2LM4T6FrzwdyNtsrI/J0FaR9mO0Yj04K1nK9uU1EK3mAYuwyVtVYN2kbaGd/Mg8eOyO8+3tMUlAvJwnqy17Xawf+2pac/kKqJvhw/6L7dJupbwPEUKcRcIcbC+xR4IUr1sundzrFQ== 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=SXGrPsUSwM7UDTr+Xy8l8D/8QVX2s2rwHYeg+bJMefI=; b=ROMGnPACtPoO8aoVxEipSDgHTaWGDZkeHNaI1OLD4S6wIs7jSJ0fh4C/GALHvwFythxCuC1TzfFGAqSfM6ljCVTWPI0fI0yNxuJTCiUmBarsRxiJs9SDiQXMRByk3lcIg3s+PFmBJAZ/iGF8LB9RAzy098UEpGPAkNN1u2nPsL9sXyaI6Q1lQKkZ+z7fAlYp543HV+FUAw/y2GfLf771oxTnMsmQMz4d6t+dJ0ZQgLnv6w9d5mAyJ6B8IbETtzSzMCksN5InYhcRQBEqLWFTVWmYpfNjLSzyBBm6F528HsyaFxcK0u790GO6WEduHrKoZpk4xbly1ZLsUxwyQQAIbQ== Received: from PUZPR06MB5676.apcprd06.prod.outlook.com (2603:1096:301:f8::10) by SEYPR06MB5790.apcprd06.prod.outlook.com (2603:1096:101:b9::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7741.23; Tue, 2 Jul 2024 08:46:00 +0000 Received: from PUZPR06MB5676.apcprd06.prod.outlook.com ([fe80::a00b:f422:ac44:636f]) by PUZPR06MB5676.apcprd06.prod.outlook.com ([fe80::a00b:f422:ac44:636f%6]) with mapi id 15.20.7719.028; Tue, 2 Jul 2024 08:46:00 +0000 From: Huan Yang To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , "Matthew Wilcox (Oracle)" , David Hildenbrand , Ryan Roberts , Chris Li , Dan Schatzberg , Huan Yang , Kairui Song , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christian Brauner Cc: opensource.kernel@vivo.com Subject: [RFC PATCH 0/4] Introduce PMC(PER-MEMCG-CACHE) Date: Tue, 2 Jul 2024 16:44:03 +0800 Message-ID: <20240702084423.1717904-1-link@vivo.com> X-Mailer: git-send-email 2.45.2 X-ClientProxiedBy: SG2PR01CA0148.apcprd01.prod.exchangelabs.com (2603:1096:4:8f::28) To PUZPR06MB5676.apcprd06.prod.outlook.com (2603:1096:301:f8::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PUZPR06MB5676:EE_|SEYPR06MB5790:EE_ X-MS-Office365-Filtering-Correlation-Id: 4992ed90-2588-4b32-53ee-08dc9a7365d6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|52116014|7416014|376014|366016|921020|38350700014; X-Microsoft-Antispam-Message-Info: h84zMWQXmFIh1sM4RDIxu8tV9xTtZFUOakoesYfCqNdrHRF8n1N3ziF28v6Kamg0MJvlaY11iIBOjY7RQYsG6rX5e63E1C5Hyj+VNLsJUnsQIUf2MHaQ3YxW5/2Er5S+b4t5VIkPNIBqLwbcf2nNyy7kw95IaDtQcvrWYB7j/7PF2cRD6B6qPol7KGnpTE35018/56tDJp72XBT8lPX8j2UmxI35AMIpH4mHUVy0SwdrPwZcUju08pkOH/2gGTt5jgig593T3ZUkhfN/SMjZutGJAkq9opmTrRcFSFvSOI6D693VT+2a249v0YmlLb2DCRGb2wXxe43Qm6L3YC0qGyYG0Jfyfl3PtCSjDwHPg65QRZOC63dfeUGIVPVx5mnPFiYgjLCe4vjdtlTNGVdRNu3e33ZhvaSwflrYQZb/Ga0I262aFhmALbz2uxzbySE1LzCExaIuSeVAr20vvkNs6PXFmZnLX9J7sM0SpcxmHb0wuTfE0211IrSVgnUg/9Nahd70rzbXqf74nnuIWFKFRwoOJW6/mzjAPKNYpoizcD+yCqMOQA9/FfxGxqvoY7z18A1Hqq8L8dQbNg0LNL4l/srVgBngX0abTAVfNXjIOl9guQlbxBjIXqhCndpc1W42JCsFSswx3Iht8Rz4pp/MnRfhO3/+r/oRzOzkejvrxbxo/OqjRbDG1w5ZAdkD+ZLm3gl0xnxyEw+qVzPJK9Wl9BSgCGykSii8pgZjKhIfaVmRf2zEfuMsFXkYbgG0aLTmuwujMllOnK19ZivnCOSxt3BUB3RMMnQF4kvj3/BF/rAecBPE9kwzdpRcvb56xcLBspJh0MWFeKtXrqRCxPxiVXL168HkWkSzYiT5e3gImTQqkfTl6khhnk4ceXhK3PnqbiQms83/UctmClTD6eJx+f+XMADUPCPqGlBfPpZ2cSku1KWfu0s3qdrxkcu7Vhn0HgwyzpUNeS+Qkg/DcwnNA9mBBaoE50cXd3P13zqrdaTsgD4psLb8UYIywLkgAmJxb5RRUNIGhEGHbY4/p231h9nXc5urm7j4lzmG1+M8I2foK9xOeoZSBAigd8pVjNCBNsi4/mrT+cEK6uihb08GW6V6HSLDl7ftwXVkEsHIe4Ri3fprZQHW9aruj4XNJS122p1tq0ywlPYK9mUcQMRd9rxzcY0bhyNZcFKrz9ItNyuaQKgnRSrO+asrp24FRuaevZivh4dlGKuy546jRUXf/FYRVk2eCVEGSEW+nuKei9uJ8SJIsi1ngr9Kq7/aW9rCApOpLhay+/x9AQSsnaQ3gG92wz23u2ITXoYQY77N49JWjvRPb6uIcdiD+x9uOo0jVaCBywNQMZFGgjyFZ+YMEA20HFkDuUrqRF3pGCQfAbbU0jED0QD60ZLZMPPBSJ7Y08AQejhiau0fy200BedsuoMn999sVi7GpaD/KM3rPd0= 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:(13230040)(1800799024)(52116014)(7416014)(376014)(366016)(921020)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: gwyimZQrAL1xYWgVLwD++pjfed/VfyHTJMLiAvLbOExlIYkTpgiWeGF+WR8KPPxu37XVGqQt6MjWeWymxwL7Kql1iWNIDFlaMs57N2oiixDYzlHtmEuYj+pgmS8h0VoyY4Dpqc2mewzgXUygV2lXRvL3o1UI3nsXKF2MGask84XA68SN28WboUQ7fJ+VtCrd8Mv9XDaWZ4gcG4jJ5Mscxn85MfjcaZDU0uNbHsJHWULFYTXznqtAKQ2YnV/Sy1535uWNvJnNAAoyg91W3nI77Uahudp9b7dqywsPE98hQp4nM86jNVXiH5nkaL6j6CRi8zbWADaZ3CgI34AgDaHdkoxCrMwWV0YRxrzEaXyb/7MYsyKSDChZUbxPHsvmoHVjFOD7vB/pWa/dapzeDFj60K3/W93cSgtgbdeCYxer3cnjXIpY7XuE5RDnB5WT1d4UjfjgUc1kJaSpHbwU4W0UpK72IV6Y/gks1ePoKQsR6O4/7tWAkDBhUhP9ucR7Ga1IlTjMCrCF66HjW+jXUDV72M1VW9S31aDIUKGvCk1pVla3TDEZGcjCTmH9pWfI6PkEUv+exPkJej7aqDMrpT67lbGoAqeFbc+bfzN5zCZJV3ZofTYMGkkqW4EzZ76LUb8EfdlXgwCuwfXuSzUFrII+wVjknPZPoiEV86lPMuPoEiAgk1HIzeE1vs4NC3QA0ltkWTCW8l+FWzTRardHaHlqulBdMUKdc9+4Tft+3rpMZfBScLQI/kKmtzErRTD5zHKf3QqZKXCghkPcYESahV0urUmOnW6MuGNwp2IqYegkQfbVtS+eOMbHvdp7rpzEew9Ui36OM/d6fxb0RNgnjzhJfMcz3W17/LSx7AgIW4lyhCEg0HDUGd0m/kLCLlFlGOTdBztJq1RZQJ9Ua5DLzBJZeSKCC/68ItCxpM4njt/yv8fNgl5mylGlPrcQYbOdJVcD/6MHJxGK5u5g3/e3jSieZV90flx1wCI8blIYmmL2Abf8DG/EmCC1DYVKCrrY6DbBo5752swN95OcLjBZjcJi1i4Tsk4FgcXeAXbijID0NjTMudjJcOlXz5/ajD0P2yYdBJL2B8uyqMPQPqjvNNn8IXLA1nkLRHiQuVUBO4Ud5VVk9+2W6iZq0ZEnzKTKSTwQSJogNBOvVekr16/EV5peTBhX/v9sZMOm4oNy4e/k5hTtDKBHiaKDxQFqNjV2qHoseoILAKxhkfFOMApPM/LFrYFGb1NwjJS9WZynJu5t8nOcN2zGBbQgg4kKjNjbxSicXw//B3as4IsZ5LAMB+abhQ2Qqq4DqzX56JrdCFAnKeWtMYvOiwy+anKBP1LRIclCDDicoMcNtzdXnKQhFHO9PZihqykg0nK/96rZH38PxN5Y9LGnA35CvbE+Hb9YEVblr0tNmiyRjvMZ5CaBKky6IiX0A5tNYL7sJ7jRgVvEe9BLTzutIf2bAl4ZDz4DRsZIo7T71VI5sEgFG/hgR5CqqnROvvfUDJ4FRS3dSqD8SpwJsShCS4oMvMDLCVVj8DPBVuLzlJN+LG3AfiiotgPH8ip8SUnKIrlNFaEViMKa+S5CiZI7UcF7JGJ1jyfH8r0T X-OriginatorOrg: vivo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4992ed90-2588-4b32-53ee-08dc9a7365d6 X-MS-Exchange-CrossTenant-AuthSource: PUZPR06MB5676.apcprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2024 08:46:00.2260 (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: q8TFlp5fZ2MqMFp2dvTItqU7VCox4A9xraQUzn9bsIRHfGhlPBlJcONY8IsWrBw6IhI6wRNXxTgyxLOTejpQZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEYPR06MB5790 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 49B1E80004 X-Stat-Signature: rux6fxfc9h6n8w86m91ygtfj9t3e3x56 X-HE-Tag: 1719909964-286648 X-HE-Meta: U2FsdGVkX19p/lYMArKws/FBOI31YRro97v+8WnTkEU54G5fNOv/tGaFpPwj7+1UH3MXACGK3oSUde0G+ObUtCDW1T0pJJBFVsMWBaCjpfY80btxKHi3qyu851S/i4qsw1qSHClch8IgwPl9eELClkojOzIIA3YIRPPxvwVJxDZ6F7epZ1L1pj8JPWabjealND8ZoY+NtrN0E+YM4ZpOHVKvW+oTS4FAMwHaWo1YFBb2XOaQEa/5MC27jG9UKD4D6lrxFbDfSx8HQnNq1tCgctitbKd6iemddWdWnIPWZHsDll/K7i1zBYa7C/kQ3zKpCXyOKow6mp1o+Cvcg3culBA2vYWK4VIHJbciOS9S+ZHxyXBa8YvT4CSM7UGPxYZRrttgWfRlerjCusMD9wydXUaGWyykb0Rm3ZPkvqtSuEbAtuXuXPXTjMvqMmk7QVGacinErPIsl9QXcN52Bc6MU23tBnobyYCUSyZwx1oWNOzWJhcN3Q5UZyiozJzPD0oJg77Rzlc7hr93idFz4wyxI1TcKAYNlwwPnYwjCsd1L9Uyszvxp5E4UG0Qp+3ulzV3/3isC8ipXE8wN7B7fzfyPXjr2z19Lh8i+oaoBLVQs7xJVyGKYcvgyETKnV+34lcQNHYe70uRc/NsxRwoFxfRbXXi3lzbnKL3cLENWyV7fpwMrBclKqrC+xprDqvz862q2kKrrc4aT5SoHj8di3BfGl1fou1gKgAtSfjzi/58dBunWlM3t8prys/tHEhlKqpSQNcm1pL3HtfTkBh76nCGFfap5pXFv+i938VBLmIwAl2D1tfN0K+DI6fo3zf2Y/XXCVran9DgFssFr8H1fMUsUb7dTswZewqYSLkct8FT1bSqh9pPWwUqtyqihXWM5bOPDEl3QMXtDPTKh/eTc8JlhP+3+5QaQtG8xz/mqV2+eC9oMzNKV7yDlZf7ZWcjcDax2Y9R9FrcCuVUrOFnvO0 hMhxuaYu UhqCUOByXBAZBwPX0N5XYkOBXM4x3pdH0xBLvQZb4r0mf6DC7fuEailI91x1JaLQztne8+ldoFrMIQfmVIM8MEJXofT68SM1PZNzyOS2qjAA9ByXFyAXw/I1Kmfc1wwBGW2OUlyg+0blhbuvHNm/YYQamzATKH6puoTJtWeIUSNGUt7uAfwk3eTk7zA6YAa1BYG5YFuZq0O5YeHlBJJzEI8ApBffe/6ot/hgCOA9218e8b5r4Ho18ZwWnpDghtb30k2ikqj/Z9EBJWcU= 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: This patchset like to talk abount a idea about PMC(PER-MEMCG-CACHE). Background === Modern computer systems always have performance gaps between hardware, such as the performance differences between CPU, memory, and disk. Due to the principle of locality of reference in data access: Programs often access data that has been accessed before Programs access the next set of data after accessing a particular data As a result: 1. CPU cache is used to speed up the access of already accessed data in memory 2. Disk prefetching techniques are used to prepare the next set of data to be accessed in advance (to avoid direct disk access) The basic utilization of locality greatly enhances computer performance. PMC (per-MEMCG-cache) is similar, utilizing a principle of locality to enhance program performance. In modern computers, especially in smartphones, services are provided to users on a per-application basis (such as Camera, Chat, etc.), where an application is composed of multiple processes working together to provide services. The basic unit for managing resources in a computer is the process, which in turn uses threads to share memory and accomplish tasks. Memory is shared among threads within a process. However, modern computers have the following issues, with a locality deficiency: 1. Different forms of memory exist and are not interconnected (anonymous pages, file pages, special memory such as DMA-BUF, various memory alloc in kernel mode, etc.) 2. Memory isolation exists between processes, and apart from specific shared memory, they do not communicate with each other. 3. During the transition of functionality within an application, a process usually releases memory, while another process requests memory, and in this process, memory has to be obtained from the lowest level through competition. For example abount camera application: Camera applications typically provide photo capture services as well as photo preview services. The photo capture process usually utilizes DMA-BUF to facilitate the sharing of image data between the CPU and DMA devices. When it comes to image preview, multiple algorithm processes are typically involved in processing the image data, which may also involve heap memory and other resources. During the switch between photo capture and preview, the application typically needs to release DMA-BUF memory and then the algorithms need to allocate heap memory. The flow of system memory during this process is managed by the PCP-BUDDY system. However, the PCP and BUDDY systems are shared, and subsequently requested memory may not be available due to previously allocated memory being used (such as for file reading), requiring a competitive (memory reclamation) process to obtain it. So, if it is possible to allow the released memory to be allocated with high priority within the application, then this can meet the locality requirement, improve performance, and avoid unnecessary memory reclaim. PMC solutions are similar to PCP, as they both establish cache pools according to certain rules. Why base on MEMCG? === The MEMCG container can allocate selected processes to a MEMCG based on certain grouping strategies (typical examples include grouping by app or UID). Processes within the same MEMCG can then be used for statistics, upper limit restrictions, and reclamation control. All processes within a MEMCG are considered as a single memory unit, sharing memory among themselves. As a result, when one process releases memory, another process within the same group can obtain it with the highest priority, fully utilizing the locality of memory allocation characteristics within the MEMCG (such as APP grouping). In addition, MEMCG provides feature interfaces that can be dynamically toggled and are fully controllable by the policy.This provides greater flexibility and does not impact performance when not enabled (controlled through static key). Abount PMC implement === Here, a cache switch is provided for each MEMCG(not on root). When the user enables the cache, processes within the MEMCG will share memory through this cache. The cache pool is positioned before the PCP. All order0 page released by processes in MEMCG will be released to the cache pool first, and when memory is requested, it will also be prioritized to be obtained from the cache pool. `memory.cache` is the sole entry point for controlling PMC, here are some nested keys to control PMC: 1. "enable=[y|n]" to enable or disable targeted MEMCG's cache 2. "keys=nid=%d,watermark=%u,reaper_time=%u,limit=%u" to control already enabled PMC's behavior. a) `nid` to targeted a node to change it's key. or else all node. b) The `watermark` is used to control cache behavior, caching only when zone free pages above the zone's high water mark + this watermark is exceeded during memory release. (unit byte, default 50MB, min 10MB per-node-all-zone) c) `reaper_time` to control reaper gap, if meet, reaper all cache in this MEMCG(unit us, default 5s, 0 is disable.) d) `limit` is to limit the maximum memory used by the cache pool(unit bytes, default 100MB, max 500MB per-node-all-zone) Performance === PMC is based on MEMCG and requires performance measurement through the sharing of complex workloads between application processes. Therefore, at the moment, we unable to provide a better testing solution for this patchset. Here is the internal testing situation we provide, using the camera application as an example. (1-NODE-1-ZONE-8GRAM) Test Case: Capture in rear portrait HDR mode 1. Test mode: rear portrait HDR mode. This scene needs more than 800M ram which memory types including dmabuf(470M), PSS(150M) and APU(200M) 2. Test steps: take a photo, then click thumbnail to view the full image The overall performance benefit from click shutter button to showing whole image improves 500ms, and the total slowpath cost of all camera threads reduced from 958ms to 495ms. Especially for the shot2shot in this mode, the preview dealy of each frame have a significant improve. Some question === 1. The current patchset ignores the migrate type because the original requirement is to share between DMA-BUF and heap memory. However, this behavior will cause serious system fragmentation, so is there a better solution? 2. Current patchset only supports order 0 and use reaper to reclaim cache. Maybe better adapt to drain work and high order. 3. Actually, above internal test set cache pool free before pcp, and alloc behind buddy free. So task will push common memory, and cace will only be used in emergency situations.(before into slowpath). This will result in better performance, but it may impact the system. Even if only when application start up, cache enable. So, which better? 4. Current patchset is simple to talk, some struct maybe need refcount/lock to fix race access. Huan Yang (4): mm: memcg: pmc framework mm: memcg: pmc support change attribute mm: memcg: pmc: support reaper mm: memcg: pmc: support oom release include/linux/memcontrol.h | 41 ++++ include/linux/mmzone.h | 34 +++ include/linux/swap.h | 1 + mm/memcontrol.c | 481 +++++++++++++++++++++++++++++++++++++ mm/page_alloc.c | 147 ++++++++++++ 5 files changed, 704 insertions(+) base-commit: 727900b675b749c40ba1f6669c7ae5eb7eb8e837