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 84AACC282C6 for ; Mon, 3 Mar 2025 18:40:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06F90280004; Mon, 3 Mar 2025 13:40:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 01E24280002; Mon, 3 Mar 2025 13:40:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E4EA3280004; Mon, 3 Mar 2025 13:40:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C72E3280002 for ; Mon, 3 Mar 2025 13:40:54 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 52A8BB6B8B for ; Mon, 3 Mar 2025 18:40:54 +0000 (UTC) X-FDA: 83181106428.07.D562F58 Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186]) by imf27.hostedemail.com (Postfix) with ESMTP id 22B3C40009 for ; Mon, 3 Mar 2025 18:40:51 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=XtsQeyZB; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.186 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741027252; a=rsa-sha256; cv=none; b=WlrPb3aF6kViMYEr43BAzvhrulr2NsyZ2QXhFdMXS+AWf8Tx9YOm1tgyL+ow6XVuHML/fe gUacm4MIbIW3xTev4k7XWX8r5KM0Km84N1/5BwMifnjTyz0CMpvItXwdnPr0oY+ba/4Hgr AxPE2j7lNoxfzGh49g/wWDnlvy6MuBM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=XtsQeyZB; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.186 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=1741027252; 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=EM3cfj2D+hRqRRZcQ0TuiGHZsS+SJp4y47psfwmgNS8=; b=aF5MiyuUVhGtqtcWpIc5itmfd71tF7+520ndMqGKER0m1yGVysMC5BBCyPKMNfNq9dlIVX CQwssZDQesQVwrrHicirz7dPwm/md3DepM9S931YXBE5kh8C8fsakG66A8Qg0ahCG+i4nm h5BHgT/Mz2hiiatGculMJTPfjpq0ke8= Date: Mon, 3 Mar 2025 10:40:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741027249; 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=EM3cfj2D+hRqRRZcQ0TuiGHZsS+SJp4y47psfwmgNS8=; b=XtsQeyZB2JhTw01TKG4uxDOC4o8cZDRMjt8CVkDrHHhz4jFsHWCh0300lUQEkIcEClbSkI fXTwYKOyR/nnwBZyjcNKQjjpqlfyadoKdvcceb5ADurR9+kJKZAWNMUn/i3zSreElmHCmN yXwoPdB6h6jMXiiAcGb9yusdsviQnCc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Yosry Ahmed Cc: Michal =?utf-8?Q?Koutn=C3=BD?= , inwardvessel , 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-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 22B3C40009 X-Stat-Signature: ynz437spndbf5s1ufywahjzuq54zfeqj X-HE-Tag: 1741027251-645381 X-HE-Meta: U2FsdGVkX19Abv4UfF22lNXTjH7p9BGkb7aBNc9wl5Yo12FIv9t4O0sSpgweOg9q8SNt2einM8W6/7TYqrnKFAxl3ZZaDcSweNi7XRFiXYOQA1Ld7niu7oUd3cUsS98nrjjvWB25KJn7/W9Jsj0fquluip6GWADrNLlGDuaUWPCKS431qajK6rlx5zaTs3bsgWlCr2yvWrHLJcO/uxIALODjtW0sZTh1xTKhHTMbUXGLLEnGmRS4fI1kCBOWHEiw18/mOYPcjSXShJjY0YtA0IOzcgXi265p1EWNG0UtluQDt+iSLE0rKrE0m9H3mt7Srv5OiEUJtw//wM2R3xn4EPh0xwe6wUaFlRSj4t0AJ+3N6GmB/X7PwjBREbs4wop4fGRaD5Iw9cUDCCRpLpJ9zUVZ1409CnMFI84UT8G9lHcW37u4m53rW2HhUReJvtUvxgrjLLnx3a1Sz8K9IZICTlDHKUqq96yFS98SoznqPTZopsbruuIv3noMCYx/0mf7YwbI+iTqZj82O4513Cx21Z29Gv7qYsybprmsTDG0MgonRCZyx4mNo56H4ZRcGaWVau/OHYxQfPhygW8f1xLMxFVWZLDNuPihRekBIVkRa4rjuD5UEvDKtzRuieyAsBHeTOOkxtMFmc0SPf1cHlFvjZyE07lSg9aRB83uHj9mSZj6eJWCYK+oeUU4hJkYdj+dLU8uttTqC7S3mPq06RzpdnT0Y8xwjSAXvHT0voHP8mpI8+f8i7nWv3ekz3fYNh+G3g/psOfRkFk3AbMyGL0ynQ/zZKD+rKvcY0DKnBeAGP2T71psYucaoI9QNhzJlB02Qkb/aNCf6jjrAFh9WlnFm8XwuR4H3bQjkNF2t9lTIqFsdul5JwtvuWnK/1nyH9P+w3SAcqkVE3/NNEaTSmDMhzBkP+goz8qXAbBO8DCBHQY18DA8st9R6chrzkYfKAnStom79jcKMbNmHIElJhG eCpTEaO6 1OvNt2MwN26FZKDGfeB2EskZE4rUrD+7/shXDKQ1OB305F9r5GMarbzRWBCKJBwY+PJVJqPeSGLzwq/dwKUcBMDv2Rx+3NyayOt0cm9VpYZtBdT1XnxCifri2C/FVZxAoJaWvbAv8TZ71jGoENdD3gaAi58adUegOsplZdtmSBe4CY3RL51a6FFgpPAgtAph0UcR5SFEmU9R/yxCqZNdPgFq2y0KzHL6FjLmC 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 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.