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 7E0D2C35FFA for ; Wed, 19 Mar 2025 08:49:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2676280002; Wed, 19 Mar 2025 04:49:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D4D2280001; Wed, 19 Mar 2025 04:49:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89C66280002; Wed, 19 Mar 2025 04:49:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 68BB1280001 for ; Wed, 19 Mar 2025 04:49:54 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EC603161C07 for ; Wed, 19 Mar 2025 08:49:54 +0000 (UTC) X-FDA: 83237677908.29.EA1B74A Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf18.hostedemail.com (Postfix) with ESMTP id 685E51C0005 for ; Wed, 19 Mar 2025 08:49:53 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hGdB2uec; spf=pass (imf18.hostedemail.com: domain of brauner@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742374193; 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=esrKPE+XtZkCtA6mVmySTZEnEUptxenfnRf7QGDwGk8=; b=npZUpXMdJRWdn4i+MUMZMcOKe6y/+nKlzq2DBwozsGiv34V2Cxob4Ynn5TPR8HyL2J+iak nql0Uc4FnWpi5CpaUbYqGLFATEKM2WbbUWR/tWxqHt9O1nLK8atIrzB62b+XVP4PxEZpl5 E77Kh7hbaRCzkqjLAMVjxyGjtSZ4x0Q= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hGdB2uec; spf=pass (imf18.hostedemail.com: domain of brauner@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742374193; a=rsa-sha256; cv=none; b=6Vd4AENsAC2K1lVX/mRQsHx/HK++ChWtiyo+umzT52FA/UnJ1PzQ7BdoYLFRD3djdhpsHF GKQLL0DiKaDLVgjE4OTC6WKSs47IXmW2ZBfFVjU18suz0Ye8VDabsrETeAXlfxz1V+jPH4 SzsFd5HOmusorTLjKjxl/+A4ulCNbyQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 897F861145; Wed, 19 Mar 2025 08:49:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD5A3C4CEE9; Wed, 19 Mar 2025 08:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742374192; bh=lx+Dz04qVniBpkYjSNsSv5CTf5H350F9KJyHsvtn+5k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hGdB2uecv27etQuxojmESrwAeCjHfkkcwCG/FME2yLecBXHixffp2l3SlUwG1lM5V PHoAw8Gnc5tc/3Ti8sWtmreYp4DMwbjlxWUipyMOfi/7wy9Gq/dX0xDI/24f5rDRrD +DMuVB3OnMrnebx1UnskxX7/PEOnG5PiO2SbV6l7mU2nxji+d3i9SmzGTUPvogg3vP iprGWbA9evz2fDD7r9NkfTxF5VEpHIKy4nDZze6V3HiYAabpRUrWizEaaL9i64I09v eUpT2iiOY6EVqNHB0Fd6Bcc3pYPXGgSBD4rnc+si2voCTGsyPh6zCsYVtbMZtShjff ge9nmBGk9+2WQ== Date: Wed, 19 Mar 2025 09:49:46 +0100 From: Christian Brauner To: Shakeel Butt 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-pc] [LSF/MM/BPF Topic] Performance improvement for Memory Cgroups Message-ID: <20250319-imposant-hausarbeit-cc56f969fb6b@brauner> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 685E51C0005 X-Stat-Signature: a5iac536bnggy8f8x9a3wixksp5cj6pb X-HE-Tag: 1742374193-947754 X-HE-Meta: U2FsdGVkX1/Nk02SMjPxauKw4cmMnsLqKGptb6LzTV8vLHveBx2dxnfglzOX4dkydKYX0TVvVm8AVOoE0OOUAvaldEDX3xVA74XEgkySnCqDWWS4TzdmNxucjs3ekMaYXS3GYjWhSlnW/z3Kxg9CIUi5RF0ltZ2yh0h9ncHlZQ4+qP3VH/WQzW5HhyPFHdWVjNVNRBwK3x95sKvzA7BvZsC+JH5oI81gAIsXk5iNqvF9X+osFxqE4TKZ1t5J768qYuzIn7ABOasv3gXx66xtQTJePA0dphW0M0Pijm/whOmd/A7A+8qhI4eM8Z9xWGOL7jnv+9zoRWp2UbTJWLUEl7b2z6a/YxrFz5hISO+7Dgb13NEItDfXmSvirXpORI77EJG7pRqyTm+OLbvREdp0TM3/qMtmogijoG1qhd3zwmM9RG94++OpWxebtR0/JiFOSqr0LDVbpwWylEnIodbYDP8aptO2+PcjJNt8vuEyrO3oD6mDqQTFxQnANUmSiZ7kamNfLZujdLHs7QMpH1tEuEQPPuoCUv0kqaLOz21aTuSKhnNLOCsEdBr0Vo8ihvF0keM8Bu19iI5hm3Rd0LieXuLHTEBMdewee4y46xv26ZkgAJ9s42PY9fhYFKmIAm+ZFTrrQ9bEHDOGgLWLQxn61aE0ESuqFxNTG0DcIA/hbiJfQkJ6mVY6djw9ygv2bM8StAnMgK51TqoEfifdHJxGR8AKsdfZ0eBhA7+7GSMM/gOlHcYelmp7MqpqFtY2uDGVFsDPrp4kd5+nqT/vT300xbrAX0lEYI9XNHnGJaxQ+wE1AtDJBxqY5mZEm43kvYZqJSs4Gdvkm1Xr4a3BrixalRdigivY+NAg0ddwCxaxEJ1QhCvUL7PkXH63f+jRGVZk4e21JlKLusSD8pMFNM8L7uXhGcR0O4r48kbQeQpgIQNTZ3zEcoGcIaubp/uhJ75G2qPqiGZ9kLBeMHPoOqf 9myHrvf+ J+upBZIIRmBqn9PErcLJj5jr3elA4LrNDu/jDxPGvfctMUcGtw11Pm/+Ke8bNL/UPTg/3MoP+w/B7FwkNVnDTPeEfJoQ7IDySEdwuOyQ9EGhRGPMlELtWHtEbLfXYqA5HsQEQjlpB6DzoK9kN5US8XStuMwOQgPgyRl/HM+o2OEMinquxCtAhDKn9GOGp4c4vaVkLcvFlZ27icStJoOyJQLuiTsdJlKkeUyiCk2aQnkEp2MLUZiC0kl62uZqSKFkICaG7H34RcO8iyTgkNu/4zNlURC1+rmOfimXPCme1bHVMqChByFdhCrJWDpSmFBMyHTZ14ax0DqaMNma0EtyGy7HqEOkph8Xfv7dmLFs4Bl0kHrakN2JaOcTzYqmPuNm1uAuq35ldTpQX9oZnvbZK8FBZHykPzcNoR2wLCV3h7Jrtmh6ctZBIJ+5CKVVtfxzCVy+TkKV+Yt5tomUJPMDs67pDE2DKF0pEX5OQd8zqrbktYY3RPO/xA+HZnA== 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 Tue, Mar 18, 2025 at 11:19:42PM -0700, 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. > > 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. > > One additional interesting observation from our fleet is that the cost of > memory charging increases for the users of memory.low and memory.min. Basically > propagate_protected_usage() becomes very prominently visible in the perf > traces. > > Other than charging, the memcg stats infra also is very expensive and a lot IIrcu, it also slows down opening files significantly as we discussed last year. So I'm very interested in improvements in this area as well. > of CPUs in our fleet are spent on maintaining these stats. Memcg stats use > rstat infrastructure which is designed for fast updates and slow readers. > The updaters put the cgroup in a per-cpu update tree while the stats readers > flushes update trees of all the cpus. For memcg, the flushes has become very > expensive and over the years we have added ratelimiting to limit the cost. > I want to discuss what else we can do to further improve the memcg stats. > > Other than the performance of charging and memcg stats, time permitting, we > can discuss other memcg topics like new features or something still lacking. > > [1] https://lwn.net/Articles/974575/ > [2] https://lore.kernel.org/all/20250307055936.3988572-1-shakeel.butt@linux.dev/ > [3] 3754707bcc3e ("Revert "memcg: enable accounting for file lock caches"") > [4] 0bcfe68b8767 ("Revert "memcg: enable accounting for pollfd and select bits arrays"") > _______________________________________________ > Lsf-pc mailing list > Lsf-pc@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc