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 B9C86E77188 for ; Tue, 24 Dec 2024 04:57:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2090D6B0082; Mon, 23 Dec 2024 23:57:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B8B36B0083; Mon, 23 Dec 2024 23:57:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A8B66B0085; Mon, 23 Dec 2024 23:57:42 -0500 (EST) 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 E176D6B0082 for ; Mon, 23 Dec 2024 23:57:41 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7F568804B6 for ; Tue, 24 Dec 2024 04:57:41 +0000 (UTC) X-FDA: 82928643504.10.3AE9304 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf10.hostedemail.com (Postfix) with ESMTP id ABB79C0002 for ; Tue, 24 Dec 2024 04:57:22 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=r1+PmMj9; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 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=1735016223; a=rsa-sha256; cv=none; b=8iwaiHjqEJpFt6yUAa2kuaMBAqEFDZq/F3DFX0f2cKCY3oWvMcZSYN1CfD9AyygEiD4KVj BWLtiHn+55OSuP2wNcKubjT2GT/MTcMqgcnl9pJtewqrXz38BByNbiNaItMA9MD2a4wVhi qBJrgHJCTlpta5zRnxXRNqvV6WN4oqs= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=r1+PmMj9; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 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=1735016223; 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=OUPhD9D/XyaTnxrbpjtqlaOp9Yy/bl11ikmJGQUgW9E=; b=YAJ1q1VSqMTmH69Otd0ajzovYjWJMpssP3RuLOwNhNnfWLWVtTJJH3AS/D4fP92TVDX8Ed mb0oR0Gv4L+kXdpPf64ZrWfBwd63mCV3meYbP6PmMVA9RtfktoaCoWQHuudWMpyPDtMU5K 5RHu7tggRX7x3dJirdePV+q+M1qeDLY= Date: Mon, 23 Dec 2024 20:57:29 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1735016257; 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=OUPhD9D/XyaTnxrbpjtqlaOp9Yy/bl11ikmJGQUgW9E=; b=r1+PmMj9ijyIFFN98Gy8llgZxZSsycRqn7QkP1tGUzMrETvxv6D53K3tVmDlRiU7BRpPl+ NftWsY8e5sALp7yQer5UMoXOnK6+PepC7Klo/CjhjUH7DUWk7BDU6+/jGYmBKhoPXLnK3f pJqGkQbz0B05xCwFNRtI5QYVDLMCjS4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: JP Kobryn Cc: hannes@cmpxchg.org, yosryahmed@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, cgroups@vger.kernel.org, Tejun Heo , Michal =?utf-8?Q?Koutn=C3=BD?= Subject: Re: [PATCH 0/9 RFC] cgroup: separate rstat trees Message-ID: References: <20241224011402.134009-1-inwardvessel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241224011402.134009-1-inwardvessel@gmail.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: ABB79C0002 X-Stat-Signature: mkcs4fgqfghich39djt9ncfbhnskt4ks X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1735016242-322219 X-HE-Meta: U2FsdGVkX1/sAM6L9rqy7W1Fe0kTfFrM/j3IdbcYPic9BDnasIk715bKr2Ndvc8OkRpQY2vid2l25CzA02emXksgegHlilyTKAZQrM06g4pxzBwIYTnjhW6FETWI6Ol8a1PdOj+CNS44WlikkQ04gvd1jV7enotFbAaMZfDr/JnDDv2lp5EDGYK+54tCRm4/o8TI8KAN6xT4RDx+QX5MqZ9NBRzGAgkozXPCrMG2jamSSRHJfvNNRBYJPW5ajpAf7D1eMiiryjJFwj64qD2VFXOkWWFfYS4aaHT1cIzme7JOTsFjcZqnkDouYtGwQ6v/8CbNo57ANTkzrimv2zqrc28ot4HncJeac3pO4/9CeCpB+KbAU+ut+evdSGV2RHloP0Z5djuQDehdwk5G8a2ihmmJPco1stYorQHZCKczM0JUNthsltop20sVIPMOL7/24WXjTHLBlNRq1Aa2iw/w6ZELNmWyyk5KLChIIQnv5pntQK3sOj/IljrlSeyoP/o+IHw2NQwhGqTFJeg+ZPgL3ZmTeij6mwXlv1oQo37kXmAq+nFXILZCjV51Jp9Owq/Aek2Clmioj6lZ6wZ40SCiIJf3FY8SCQekjAKo88TiB2PG/J7v30MFrAZi+pR0B/qxWwHPatDEXyKTIoZdg0AWdWBLy4JyO3WuMTDK7Kvkwl/79L9C3gYydwRFRTdwQZG9ecLAA0iOoXHBTbY8jWqfY9P7m1F5gdAVelIgH8daVhKd+Y0C7YhWibD73MaLyQVBq+kOMdSTxD06tYWIZzj4h/cyYa8ghGf9/QJgjDcXGzoEvNtbJ2DZJp1/7YLPHb5dnG8uMEKtJauRI7lIXRMnGGL4CYq6WOly/bFkAKsN90iero7CzWLapuLfvHVF03i2ZkHVKNX72FnbQCQRxPdgHPYuToJ6kjJjVVyUp3/1cCzVz34TcmVIpaFFmxrNeifyGi4FWTtR2oyC+fPyvc9 SlS2I0du vp+L+E1qEFuDlEaFp/iIS6IbgEH9K+SX2zUPpJ6PwSrbbkLuXQfr8vOQ5kjR3Lbke8vR0jkcCXTTGtEcAjulqXdmfxbN9MRXqO0HrwLl9WPskaqDKSkQeD1nM5qmfeOahYS330YXilvmd6C2TLdPVe4i7cw== 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: Thanks JP for the awesome work. Please CC Tejun and Michal in the followup revisions. On Mon, Dec 23, 2024 at 05:13:53PM -0800, JP Kobryn wrote: > I've been experimenting with these changes to allow for separate > updating/flushing of cgroup stats per-subsystem. The idea was instead of having > a single per-cpu rstat tree for managing stats across all subsystems, we could > maybe split up the rstat trees into separate trees for each subsystem. So each > cpu would have individual trees for each subsystem. It would allow subsystems > to update and flush their stats without having any contention with others, i.e. > the io subsystem would not have to wait for an in progress memory subsystem > flush to finish. The core change is moving the rstat entities off of the cgroup > struct and onto the cgroup_subsystem_state struct. Every patch revolves around > that concept. > > I reached a point where this started to feel stable in my local testing, so I > wanted to share and get feedback on this approach. For the cover letter, please start with describing the problem you are trying to solve and then possibly give an overview of the solution you are proposing.