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 31171C36002 for ; Fri, 21 Mar 2025 17:45:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E180280004; Fri, 21 Mar 2025 13:45:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1936D280002; Fri, 21 Mar 2025 13:45:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03186280004; Fri, 21 Mar 2025 13:45:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DA6B6280002 for ; Fri, 21 Mar 2025 13:45:32 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C22D61A0486 for ; Fri, 21 Mar 2025 17:45:34 +0000 (UTC) X-FDA: 83246285388.25.B003E56 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf28.hostedemail.com (Postfix) with ESMTP id 6A5BDC0003 for ; Fri, 21 Mar 2025 17:45:32 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JU54TaIF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of inwardvessel@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=inwardvessel@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742579132; a=rsa-sha256; cv=none; b=BsD0leiVHkOhP5Cf2LCUXJ+ihwX5g6wGMTaeYdf4KhvY+R8rhpR0VYbulfjZg1sY5IMn6/ R+qHc+nKcVC6uSnYpjzX/E3FElHhBuPJ1BD/wqNdWdZGeqobFKd0e57gTQM842SyTBaoBB WFRISYr2o5CS7OAtynWyKr7O9QYmXaU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JU54TaIF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of inwardvessel@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=inwardvessel@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742579132; 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=FGUkFoO4459AC6cSpEGmTy2dO+y56Fth164tavOfDuQ=; b=m2OB+A0Eie6c/KYrytwCWPKStsqpCo2P8pvQ1g+kr8gNvgkeDUaZNRBTYLbZwuG2zlH4pt zzwdA0ZYvzYaoH0Lud188ixOoyy1h/e+DVsO+3UYWFULcOwnm6eApAGACf0R3pu4xoG83A ffqiIBkKzffPyfxSPKrHZ21D2fh8/5M= Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-2ff4a4f901fso4406840a91.2 for ; Fri, 21 Mar 2025 10:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742579131; x=1743183931; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=FGUkFoO4459AC6cSpEGmTy2dO+y56Fth164tavOfDuQ=; b=JU54TaIFknj12ve6bFmscmmVYVJIZ/55eZL2TUbPPFMtdSOWQ5c2GP7VPOg2/b2Ozk S9KnHhH6PiCVivaYZMEJ1r3FcGiN51QP10dnG6/jR6HPaf2OJkYkHMFgMZP+7vMAqKH8 wqFCL2jHnZpdM2Rp7ilpcCC0Spx8SoO8yO3+rHTtsPBE7Xy/ydf81pjRR9WlZ4EE2FTI /lTiBtd/+/KgJjAtdB0f5ZPVYZ/1lOOWgE9fXo0HfZhWN/FDp5dAGBnWIBGbQ/+YrFN3 gcfthGCxIArGFo25FQ73ZjjBtYRr2m11UDQGi8hfGrn53i3uXgHX3INNqyrS+IT+L20I lu8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742579131; x=1743183931; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FGUkFoO4459AC6cSpEGmTy2dO+y56Fth164tavOfDuQ=; b=JCtH/oDMO1BlxIMtKVCV7RZhuq2EMyOK00js2OQGSgvmLFa8C7Ot10wLXlGpTFh75X 0RpvH6bcbuU+LsfM4cgNp0ZOBqRe8KwoNg5/p6KBr8gICbXQbjgT5ILTEqttm0kkNKq6 8rhmJJ2AWTNQbRzRRUO+PAEt+RMFPFrNsf2LtroZsKbXhQ8VYget2yGBNYGP54LR5UXr eZl0zZPgET8ZpMVvPSDbFqqgIL9EXEvhKRVVOqReMYOe9RkQ9LL7A83CxaSfORUCBEIW u3soMsG+UoHgqTMIXL6/nGF7M/WjFkRKmUFi83p1x5xRAcq5VuT19mRg54lDlnZmOPMs haUg== X-Forwarded-Encrypted: i=1; AJvYcCXzokpbbmw4K6wFDjSdeWRqrNOyTzf38przk9msByKDmjWx3xVGQb/pGtXc6ysErn79C37SzCP7kA==@kvack.org X-Gm-Message-State: AOJu0YxIir0C9JHvGmUWcP6L5Fmys/vzNFnshvpthEJXuUOHsYTTn/z8 TgxH+H+DQL91kaV2zgrndGESWKX7Cm94SK28cD08cMMiKpg4gCmx X-Gm-Gg: ASbGncvtG3apQvg/LR3GziKHeaOb1fRX7tJTnAWVjZecmvdukx91D+zfn6Na9T5J7j4 TcwIsqFnvFJbGS4lxvMuwOsIzLLwwgYZuYtdfZE+1E0ZGOlaHbbko6c7lD0NJ/gV3dwgtvgAvr9 7i08Xzr9EuJTlRCaooykLfXlEtBgaE8ffpC3+YdD25ZdBPw1KJ2z4eWmbAS9XAFAZYabET6mpfI +Vtwj5SfRutvElqyEp91uoerAi0EO8GPIBHDSzE9jdGoXggLdQlxsScU80lABGCnx7PaI006eq3 F79cE1OvuPcEiJYDn4HYkTliYixcq8k/dOD/5sU76SJ6N4BCIad4iZ0ZdjhTFYuTvj93d5QNxbr XzvxqX2T6hBV7tA== X-Google-Smtp-Source: AGHT+IFWCDfnXCaMmy4hkd8moLcdPSod9/cAKjF9NP2yYpUe+jYxwO97go6VgxVfEK6VVfPKJEqCWg== X-Received: by 2002:a17:90b:3c05:b0:2fe:99cf:f566 with SMTP id 98e67ed59e1d1-3030fe942bbmr6430149a91.13.1742579131089; Fri, 21 Mar 2025 10:45:31 -0700 (PDT) Received: from [192.168.2.10] (c-67-188-127-15.hsd1.ca.comcast.net. [67.188.127.15]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-22780f39763sm20199895ad.10.2025.03.21.10.45.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Mar 2025 10:45:30 -0700 (PDT) Message-ID: <5062846a-7b4d-4c59-a990-ae9f7fd624a9@gmail.com> Date: Fri, 21 Mar 2025 10:45:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/4 v3] cgroup: save memory by splitting cgroup_rstat_cpu into compact and full versions To: Tejun Heo Cc: shakeel.butt@linux.dev, yosryahmed@google.com, mkoutny@suse.com, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org, kernel-team@meta.com References: <20250319222150.71813-1-inwardvessel@gmail.com> <20250319222150.71813-5-inwardvessel@gmail.com> Content-Language: en-US From: JP Kobryn In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6A5BDC0003 X-Stat-Signature: w4t1d9x1p1otnwic7d1957cdp1h7m15c X-Rspam-User: X-HE-Tag: 1742579132-697194 X-HE-Meta: U2FsdGVkX1+Sl1QemRBW+9mfS4zE2OipzaagcSMbIb378944ltCoHRKBtXj86j/uptNyLp8Kv1rBbWCslThhIqImdwOUtJnQIoDTQlpnsRmZSopBrNDSX6tz1NfPAutUpHVJGWCUg3c+HM2Fjb+Ub2JwS0+Lh7aZd4JEKh5RqflT7SMq4jnj6IUiC2RGHLzZ92OeeY8ISTxrcluMg1PXMh7/iHAnv/icPrOYdBakfcR9uoY59Er+QaFpaopZ/aDBInX+UBZkEixiGeohy31dZ/WSOvcuTDRsjX0P9TI6J5b3wV8d3nWQTABhlzwRfU4ZJlCZHDRrFLSjFH2gOoBdOcjSRhSgXJA9SU7k7PPNhRxULuzueKGS9p2KcB7YSar4X8o+LXdjeKMoT9C/iL0ip76jUBEa975gd6mPYSzJX3dqZTIFEq7QPJxlDOvFhydLD+NUKPWxZFuEFFBV0DUd48JYLgrPFL81k+4KJJMmlXgt56GyqGYIuwywKFogc0LQQv7KqmlcNPVwsOUmmnX6BPJGVRfGY+J2rcLCTUIcHbrKmaXV8k4UpV8SfRCblSLV619As8vMDKwboK0JGYYhnxw7B/4UnyUKHVFO5vb7WR6ys1hMz7aWKgPLqAz+5h0My7WgD98/Y8K3naB5myVy3llMWDhQV2lzd8ROhTX7ziTXS5uKE9Vo6w94lvniVUL4J+H8Q9WILZ0Xcp3lXgiqHXEa4MRQ7bum/sVBi7nPfozhLY9g5tRQLT5BXgxle58P/XN1CyXOa2OKhcbBtmiaFqiChdWYbX1qGfWPHyt4S8CGAM4py9dv7wyDaQmKUYw3cmKukKAreGda+3NWpN9nPEq9qqDRUX8Ihvh5FsNZ4Ova6PbPGI1LgZDQCVG9TGMT1tPlUMyjqpe/Bbj9Cz2s26QtN5rBlwkQepcpX0+wqfaCD93sbQqoh3C29ptQmJUFT8bhHIe2rCFxOYQHV1J aSkQN01A gl1RFX0ZODDL2TdNrLqEzCzbn1wTwCR0IDFZSMXIgisOUhg+zLWseGw6k3pjpB/QJew4mmXfA1Tcik8vynm8HPYH0av9HbS2Aupp38KlbP2GjaOuTyh7/UFG3ESGUJcTcObNCiv3NQw8anzfFyqCGGr/qsFPYOCFNiwrU8OV/BNozS5OjSWr+hJpYnYzD+t9iW1gxe5BrxNhtc9QKA2GF761IY+xpL+uZUjFcpdUhriwBWdfj19csEFTiApavKHIOMKTNwWWIrH5ocPJUTG8JEn8DQfrWDYeN6iLZKXtVe1yXtp+vwjvUM4+5Sm8IQVB8H4haWWzVWTR8kyIYmV84B1wMF1fK68vCG5R9vsI49VcdMF7bEP2dNOLpgPQ52fa3htkw7kjgk7gs95m0YN3xyH/JJuY69CAy5FLRpQarjpmyAw/LSVlQTVkbNF5Nond7PjAY 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 3/20/25 2:44 PM, Tejun Heo wrote: > Hello, > > On Wed, Mar 19, 2025 at 03:21:50PM -0700, JP Kobryn wrote: >> The cgroup_rstat_cpu struct contains rstat node pointers and also the base >> stat objects. Since ownership of the cgroup_rstat_cpu has shifted from >> cgroup to cgroup_subsys_state, css's other than cgroup::self are now >> carrying along these base stat objects which go unused. Eliminate this >> wasted memory by splitting up cgroup_rstat_cpu into two separate structs. >> >> The cgroup_rstat_cpu struct is modified in a way that it now contains only >> the rstat node pointers. css's that are associated with a subsystem >> (memory, io) use this compact struct to participate in rstat without the >> memory overhead of the base stat objects. >> >> As for css's represented by cgroup::self, a new cgroup_rstat_base_cpu >> struct is introduced. It contains the new compact cgroup_rstat_cpu struct >> as its first field followed by the base stat objects. >> >> Because the rstat pointers exist at the same offset (beginning) in both >> structs, cgroup_subsys_state is modified to contain a union of the two >> structs. Where css initialization is done, the compact struct is allocated >> when the css is associated with a subsystem. When the css is not associated >> with a subsystem, the full struct is allocated. The union allows the >> existing rstat updated/flush routines to work with any css regardless of >> subsystem association. The base stats routines however, were modified to >> access the full struct field in the union. > Can you do this as a part of prep patch? ie. Move the bstat out of rstat_cpu > into the containing cgroup before switching to css based structure? It's > rather odd to claim memory saving after bloating it up due to patch > sequencing. I think it's possible. I'll give my thoughts in response to your question below. >> diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h >> index 0ffc8438c6d9..f9b84e7f718d 100644 >> --- a/include/linux/cgroup-defs.h >> +++ b/include/linux/cgroup-defs.h >> @@ -170,7 +170,10 @@ struct cgroup_subsys_state { >> struct percpu_ref refcnt; >> >> /* per-cpu recursive resource statistics */ >> - struct css_rstat_cpu __percpu *rstat_cpu; >> + union { >> + struct css_rstat_cpu __percpu *rstat_cpu; >> + struct css_rstat_base_cpu __percpu *rstat_base_cpu; >> + }; > I have a bit of difficult time following this. All that bstat is is the > counters that the cgroup itself carries regardless of the subsystem but they > would be collected and flushed the same way. Wouldn't that mean that the > cgroup css should carry the same css_rstat_cpu as other csses but would have > separate struct to carry the counters? Why is it multiplexed on > css_rstat_cpu? Originally the idea came from wanting to avoid having extra objects (even if just one pointer) in the css that would not be used. This setup allowed for what felt like (to me at least) an organized way of keeping the objects used in rstat in the same container (css). You initialize everything within the css and also have consistency with the css-based rstat API's - using the css for updated/flushed allows you to get the needed rstat objects via css. So if we moved the base stat objects to the cgroup, we could where applicable check for css_is_cgroup() and then use css->cgroup to get the base stats which we kind of do anyway. I don't see a problem there. The only complication I think is on the init side, we would have to perform a separate percpu allocation for these base stats in the cgroup. I can give this a try for next rev unless anyone feels otherwise. In general, I'll wait to see if Yosry, Michal, or Shakeel want any other changes before sending out the next rev. > > Thanks. >