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 DFDC4C282C6 for ; Mon, 3 Mar 2025 19:39:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50D5E280007; Mon, 3 Mar 2025 14:39:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BDC3280001; Mon, 3 Mar 2025 14:39:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 384BF280007; Mon, 3 Mar 2025 14:39:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1C537280001 for ; Mon, 3 Mar 2025 14:39:14 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A97A41C8F26 for ; Mon, 3 Mar 2025 19:39:13 +0000 (UTC) X-FDA: 83181253386.13.A6DB7CE Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) by imf08.hostedemail.com (Postfix) with ESMTP id B465B16000A for ; Mon, 3 Mar 2025 19:39:11 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=W6dry1Rf; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf08.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741030752; 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=9/V50uOri+cvgAKtCo8ESnh6ojnA6ZO0bR1zyNyugFE=; b=p2OsomHNVjQSIbczE6tC0V21mEsFO2MPwnLy+Lp2Xnt1CVRoAYrvXnLgwZRTl+Ky4PaCB7 DWpgt043jcAzICsHDt+M7J5V4mg8uHGIt6tpvPjaqH4W91UNE6R9KLQ2gBhGc6imEd5IAv 6hx0IwpXooZcdaU4ixlHncO6iGZSGzY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=W6dry1Rf; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf08.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741030752; a=rsa-sha256; cv=none; b=dUZ2Y5wVrJFSzcPXk4hqgfZAeET8Ckd0ZfZ+QY9mPP6/T/YOnuMnmQtSZ9Q+s9QRi+vgEb a7jy0hiKWpaOsVDTqVOWE8+E4NzBheOhsg8YyVsKamFSfGo68mguU8e+VWheWJkH2uZuI4 eU63NVOhOP7v5VpfAFEwaG4m9wbZaT4= Date: Mon, 3 Mar 2025 11:39:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741030749; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9/V50uOri+cvgAKtCo8ESnh6ojnA6ZO0bR1zyNyugFE=; b=W6dry1RfZWU+AZeUuHEdTAMl//VqzYFar/1KzMgD9PreBcNVkSFTlTsi4vw2vw3NC6n38g re53uxq0h9k+H6O093OdgjmxggO2aMFv2zktRJDZMhIqaYs/7x21+65XJcB3MZg9SE+KNS d0y8XTntUErI3TdU8GHmAYOmkQXLoVs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: JP Kobryn Cc: Yosry Ahmed , Michal =?utf-8?Q?Koutn=C3=BD?= , tj@kernel.org, mhocko@kernel.org, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH 3/4 v2] cgroup: separate rstat locks for subsystems Message-ID: References: <20250227215543.49928-1-inwardvessel@gmail.com> <20250227215543.49928-4-inwardvessel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B465B16000A X-Rspam-User: X-Stat-Signature: iefnzii98i13wmc87ar5gdji8s55q67r X-HE-Tag: 1741030751-872439 X-HE-Meta: U2FsdGVkX1/JrwSgWZpIjHHE7K4hcowA53VZjJ4nzilmEoU5hwJPVsICeJSvWOcpvemoqWX0ZJufUcglEXsQK+8PzJTdsY5CiVMypfGO2dzfvd+D4zT0o5SwZsy9oBNUclDSPbuT2iyp9Bo7slqZSFYAcGjBPSZQ9HNMuTPBfOHByKAUjMUNIpAzh3pRn+AA1s5WcFrDCfNYZKHLZvea3ExhfJmDwpmCpUKsJZFQHLf4vNQMU2vrWt9kuSijc1IB3X/jrfHC38CHIAfOoHXPlqGWPT7JPtZ32lhfO+Z/sQ8kfAzXQDpECvM7q2uOzF17B2L065C2USaCCWQlztUV16ZfYtN1NZ/qtHl9isF893coiICFd/GKraXrF2pQwkTL+9UJr8On5eH9KHHkGrmzadYKV/ahicsUd69CLw8GqzkCrLOUUThDMOhwrxO18hTdHXt8Y+wRz1lZIkmLZWNizvyWjV6+3Zu6UsVw5PNnQLPwSoyofPvqCz7LXjgVaZMsM7hy4xU2OZtngOSlaJrPa50nSAvTmvu7jUZt7JIrwSti4isTfxRm1z2xH1Xzx/KsAbSFkhDpCuxjIrAymKcAGIFyMh0CLLbRcqkr3OaHcMGmVG1Cp+4ApHUrg8idd5wWEgJgNWJMZXRBhfhq7cbkuqe73hO8CEJ8JBCTUm967G4Zd4t409PDO0/S9MMGMjacHS0jbWFqyyH43A6st0ggOUct+w/medaue092O97AHNoFM1nB9OeHv91puuWtUU01x0v0/4yxeIIpNTsMZessw58GFJMopuxbVrabKj+OJCvLT3+6wiftyWk33yrazoaA0ARqMAdDBjHKe2XHK69iTbxBdBaZD9s07T9nGP8wqDtTtxr16ushaZkgyn0vqD46rfeHgDQCFC+ZqAwUhLj0bsiZWthty/d2N6NgfOxfnKPCEyDkDwL8ioH87UAeXbF4Ro8Jy0sMYk05/E3Mj3Q CqbVgd0l k++cU7exF96lIF740tGRxvu35K/NtcrGStnLQhEwYb95TXRsFxtkMvMq4Q0NJipvvXYuYxrOOzdOnJjXotYQkfVk6SKs0J6nhKzdlPo40IGxkRPoPPjQpB5uhvbxQAFv2CAIjTMVsSOuEv6Px/TAH3INt7s5zR7G3aA/9bu6oaN5lmQFwQZEN/zEvfNlRc7S9irUnuwgT7vXtXInblqTKf+ZJAZMfteqqxOck 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 Mon, Mar 03, 2025 at 11:23:49AM -0800, JP Kobryn wrote: > > > On 3/3/25 10:40 AM, Shakeel Butt wrote: > > On Mon, Mar 03, 2025 at 06:29:53PM +0000, Yosry Ahmed wrote: > > > On Mon, Mar 03, 2025 at 04:22:42PM +0100, Michal Koutný wrote: > > > > On Thu, Feb 27, 2025 at 01:55:42PM -0800, inwardvessel wrote: > > > > > From: JP Kobryn > > > > ... > > > > > +static inline bool is_base_css(struct cgroup_subsys_state *css) > > > > > +{ > > > > > + return css->ss == NULL; > > > > > +} > > > > > > > > Similar predicate is also used in cgroup.c (various cgroup vs subsys > > > > lifecycle functions, e.g. css_free_rwork_fn()). I think it'd better > > > > unified, i.e. open code the predicate here or use the helper in both > > > > cases (css_is_cgroup() or similar). > > > > > > > > > void __init cgroup_rstat_boot(void) > > > > > { > > > > > - int cpu; > > > > > + struct cgroup_subsys *ss; > > > > > + int cpu, ssid; > > > > > - for_each_possible_cpu(cpu) > > > > > - raw_spin_lock_init(per_cpu_ptr(&cgroup_rstat_cpu_lock, cpu)); > > > > > + for_each_subsys(ss, ssid) { > > > > > + spin_lock_init(&cgroup_rstat_subsys_lock[ssid]); > > > > > + } > > > > > > > > Hm, with this loop I realize it may be worth putting this lock into > > > > struct cgroup_subsys_state and initializing them in > > > > cgroup_init_subsys() to keep all per-subsys data in one pack. > > > > > > I thought about this, but this would have unnecessary memory overhead as > > > we only need one lock per-subsystem. So having a lock in every single > > > css is wasteful. > > > > > > Maybe we can put the lock in struct cgroup_subsys? Then we can still > > > initialize them in cgroup_init_subsys(). > > > > > > > Actually one of things I was thinking about if we can just not have > > per-subsystem lock at all. At the moment, it is protecting > > rstat_flush_next field (today in cgroup and JP's series it is in css). > > What if we make it a per-cpu then we don't need the per-subsystem lock > > all? Let me know if I missed something which is being protected by this > > lock. > > > > This is help the case where there are multiple same subsystem stat > > flushers, possibly of differnt part of cgroup tree. Though they will > > still compete on per-cpu lock but still would be better than a > > sub-system level lock. > > Right, the trade-off would mean one subsystem flushing could contend for > a cpu where a different subsystem is updating and vice versa. > I meant we keep the per-subsystem per-cpu locks but remove the per-subsystem lock (i.e. cgroup_rstat_subsys_lock) if we make rstat_flush_next per-cpu. In that case two memory stats readers will not compete on memory subsystem lock but they will compete on per-cpu memory locks. Though we will have to experiment to see if this really helps or not.