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 3E8C1C36000 for ; Fri, 21 Mar 2025 17:57:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F8C1280002; Fri, 21 Mar 2025 13:57:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AA61280001; Fri, 21 Mar 2025 13:57:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 796C7280002; Fri, 21 Mar 2025 13:57:46 -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 5C92A280001 for ; Fri, 21 Mar 2025 13:57:46 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2DDBC8051A for ; Fri, 21 Mar 2025 17:57:46 +0000 (UTC) X-FDA: 83246316132.25.521F321 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) by imf07.hostedemail.com (Postfix) with ESMTP id 507784000A for ; Fri, 21 Mar 2025 17:57:44 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="RC7C/fEs"; spf=pass (imf07.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742579864; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xoAzNmFnfzdiMkINslpd8HC4sR4af0xhgYAA7hKNk2M=; b=vlYsSGbWKMxyy393km45KluLzMJBcK4vrS7nb+rVRVmh7l5hIP/ehG624+wseDn9sCB2BI 4cfppslcOeBcu7I3JysoxEovYZtS4pWPiE/v/4M4DkahJMzbjKo5PmvGymfdvwYHMVoRPC QjfoxYkesdqYN8S/RcOQ79Be98rVrzk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="RC7C/fEs"; spf=pass (imf07.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742579864; a=rsa-sha256; cv=none; b=C+DS5C4NmVY9gYWSmJa5Ix9T2U1W7hA1rjQrRJ6DOELle3GaffTQyTiRrx7118o31zzk5e NX0n8He5PcbbT/Oomi0O9R8ukObwvtQOu91eOzWGZ0/+H/zfk2dv26Fyfu3UoT1L/QuFY1 WoNwT80Ytx8lDew8jzTj8Zrp80dyHG0= Date: Fri, 21 Mar 2025 10:57:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1742579861; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xoAzNmFnfzdiMkINslpd8HC4sR4af0xhgYAA7hKNk2M=; b=RC7C/fEs8STP5WSTnAFYOj0JW78Wi8jK3yttggiY72cu7M97cnS6BPCBmcl8+Xvswt+xtZ KOXef8Ag+u7Ocr3Ou5AC7U0HSEJN22ALI/RwEVkaz8SotBAUh1jwDr3zfcSBgFknjfxLcW YxWYo3nI/iKZBDP7CQjEt9UcMjqb+ME= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Balbir Singh Cc: linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org, Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Vlastimil Babka , Yosry Ahmed , Meta kernel team Subject: Re: [LSF/MM/BPF Topic] Performance improvement for Memory Cgroups Message-ID: References: <4bb9ddf9-6f26-4adc-8f91-ad7b00074e0f@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bb9ddf9-6f26-4adc-8f91-ad7b00074e0f@nvidia.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 507784000A X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: ot93p7qnnci3bkqdypcerstuzsxcnfin X-HE-Tag: 1742579864-664738 X-HE-Meta: U2FsdGVkX1/EE+yIFpkNquc1rJHVicbwdotXlCTT+CkRrdlqFRxmcyyMpWrRvdE1WfIsGyqWfKoYG9hYh7YHx3N92smFi+Qf4+2h8bqdpLsL6/YK1dkI6nKe/eXcMw2DK4hbBLQNPk4O9qAA1J0G6CnQIUFazXF36PJfZUrYzFeSLQGbKZiA6j3o0XLZVIhs2R4nNexxlA+5iNmhQtCC7QyxHjYDjl6iQbP+/Y0IwW3ED9GGd4GUVQUyuQq0mNYZsCDrd5QB3BqaPZPxkTN8gI/Zg3tB0iILI7kJ2rkJH3qlhVOTnEdK26ykxBKBBP1YBSsQO60vzF2f6bnPsr7IO3k+VwzhJYCTKOgPhlqjCMk0v7eH6gxJBBFRjXYuKZmZ2bSlhJhR/DdzJ/DrbVk2pyLDdcku8GgWbHsNkAvx+S4QAsJJk90RbAHj5n5R+ccuTupSWdXvS3aC+UlPrQNXhST4gUaoycRSmlZDYS8q4x6KOfWO6iJDreUJHTwaMd+IyGisnAw1HY8iWyc57qXfdMAKNkE6nTPTXWQsc8Vgxb+93ctPhqbt/TbLiz/8Kfcp+IDvbMcsVi1vNDqQap8WbTWl0qYzfy/slLs1SJuH2nCv0PUZ5X+NS9W3+H1aB7ZVUbwUssbuKMHyU8thOMo1FdbNpXEhdMbtXznOz8mR/YyDiNrZGTu2u0DBqpTCkO0zufyhrZhWRnH1HEl+xwS7gnawnND21TKBgEXys2+QFzb+bXOsfA8pUIGYE9Jc6644fJ0HkKa7sKQKQq92a/w4ie3crfFgpMqMTbOmihAAwBEAb8MpEIfMpxCIuTu/f0BzZ7ZDL5TO6ov58j/AhWH4c8pDbKiqqLGd8v6Jm0dj2vimVBTA7zQ8RuacqrbgKLhH6XNIrbwLRUKgBdG1QAXoVMiXOeaqfK50QHWgkGgD8ztLjsBCOLwSO9ADlh/FPf1iSRKYno+PlPim/fjaeVJ ZAAglwrx +q1gE7GQHpHVXucWiUbx2Cth63pm+BHvATrbwkJd6e+E2ssc8vCsonw4cWwX8PEsVRoJSNMn5TsYdrP/PB68ggGK44QIlXoGXEa6vp1uXcKKMskitxBJbHJdl6fdGx7QElyqL8QWSImqSMBE6BGHU6EVtOGbaSF4eYaP506iYZKmu/mUomOfMTAN7Bg== 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, Mar 20, 2025 at 04:02:27PM +1100, Balbir Singh wrote: > On 3/19/25 17:19, Shakeel Butt wrote: > > A bit late but let me still propose a session on topics related to memory > > cgroups. Last year at LSFMM 2024, we discussed [1] about the potential > > deprecation of memcg v1. Since then we have made very good progress in that > > regard. We have moved the v1-only code in a separate file and make it not > > compile by default, have added warnings in many v1-only interfaces and have > > removed a lot of v1-only code. This year, I want to focus on performance of > > memory cgroup, particularly improving cost of charging and stats. > > I'd be very interested in the discussion, I am not there in person, FYI > > > > > At the high level we can partition the memory charging in three cases. First > > is the user memory (anon & file), second if kernel memory (slub mostly) and > > third is network memory. For network memory, [1] has described some of the > > challenges. Similarly for kernel memory, we had to revert patches where memcg > > charging was too expensive [3,4]. > > > > I want to discuss and brainstorm different ways to further optimize the > > memcg charging for all these types of memory. I am at the moment prototying > > multi-memcg support for per-cpu memcg stocks and would like to see what else > > we can do. > > > > What do you mean by multi-memcg support? Does it means creating those buckets > per cpu? > Multiple cached memcgs in struct memcg_stock_pcp. In [1] I prototypes a network specific per-cpu multi-memcg stock. However I think we need a general support instead of just for networking.