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 6B94BC3ABA9 for ; Thu, 1 May 2025 22:10:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E7136B008A; Thu, 1 May 2025 18:10:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 86EE66B008C; Thu, 1 May 2025 18:10:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 711F06B0092; Thu, 1 May 2025 18:10:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4CF9E6B008A for ; Thu, 1 May 2025 18:10:35 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1C32B1618A8 for ; Thu, 1 May 2025 22:10:31 +0000 (UTC) X-FDA: 83395733862.09.6590AE6 Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) by imf30.hostedemail.com (Postfix) with ESMTP id 341238000B for ; Thu, 1 May 2025 22:10:28 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="VlvLn8k/"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf30.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746137429; a=rsa-sha256; cv=none; b=w6nID3nDEaHozsmcN2W1ja+PbeYnJ5sLohqvOHW8wlmueWy3xjG4XFOtTz9YnZ9P94Zca7 WoO0zDeF0KvHgKaEph/imSBTzaeWrE9a6sqTDZ5ZIUMVty5EsH3s5csFFTLkND8Vqyeesy GmNycafaNfpzvwB17eDKnfIfvh0r/MQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="VlvLn8k/"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf30.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 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=1746137429; 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=T9+4ZPe0UgZes1pnp++1tI2QtV+cxnxhaX2/c7tDBlY=; b=qeX88Hc+xDeeVBjCCYs545ivGGTCWu8vbWOTG0oq40n/EvD1LCep8yO0QwHf71QuPPVvH8 jU6z+ymauIy9YbYG+Age5BrCbBgU+7Bre5K4EAGfgpDN4FaZ/b70vcU4jHXtzFbCF3JlAJ YzYBTCN4L9aDGstjikCESfYRI0FNBWY= Date: Thu, 1 May 2025 15:10:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1746137426; 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=T9+4ZPe0UgZes1pnp++1tI2QtV+cxnxhaX2/c7tDBlY=; b=VlvLn8k/VaizfjSHHuJKoe+FM8bCo0MUjVMM8xxJLHmqJ1I7vmcUaHZ1r8GfG4IoTyTCWu /l8qVCGbrkVRVkI6R5rmzHhuHbp4t+z+eYtOXOmBY5Bmdw/CvDQnJANONlovANVeac4xB2 X2VFpEXA8+16X/J09cmx94HZ00eRU20= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Yosry Ahmed Cc: Tejun Heo , Andrew Morton , Alexei Starovoitov , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Michal =?utf-8?Q?Koutn=C3=BD?= , Vlastimil Babka , Sebastian Andrzej Siewior , JP Kobryn , bpf@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [RFC PATCH 3/3] cgroup: make css_rstat_updated nmi safe Message-ID: <6u7ccequ5ye3e4iqblcdeqsigindo3xjpsvkdb6hyaw7cpjddc@u2ujv7ymlxc6> References: <20250429061211.1295443-1-shakeel.butt@linux.dev> <20250429061211.1295443-4-shakeel.butt@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 341238000B X-Stat-Signature: 88usqdix3ude63zb4dguxz1scbpd77rb X-Rspam-User: X-HE-Tag: 1746137428-548714 X-HE-Meta: U2FsdGVkX1/+/wwYJq45gSPL64b71YKiWOjcvc4oWLkztBd/CCSVRvsBUuv4I+UBkWYKwJkfeCiqOZtAriBXLgZfB7LtBSvRoJb2YsqvKci1aUqlF1wqiHuT7YAp6d/8qf1nj0Wx47J0ODvMLiX/d/fAHNKfUVF9NNiv9l0jDVBT3/bVznaXb0DEut80RwdgGvsvEdmtSbbo2igFHGvHm8dWGrbiKli9D6Flty02EkafVTnngsRtTqmaNk2kfJ+ySgylI3QQck8C0Yvyu65WSFUlQijd0Un4193GDtTG+qm+hX9bX481Q5gHyChUuBvH0g9XC1frxwS852SbyPmeLKQ5S8KpA2672nZju/OUWWi1dhOYXoDa24/Uv7/bmSAyt4bqmEYfGsoOV3BlKPdUkb52WubAAcP/2dwE751FYFbM8BhOUJhbU+x/4ARb9QTJVCte8S0NmlGdoH6oQ3bTG0ITLCAa93VVUTBwoANQJ4hPhPLEtUpH4v4yYqPb7l8nXKPQKFdyPjrZte/2Pm/4yunxCuduD3xQX9tuJFBkhxHlAACYkhGCfyL2Ih8q+mM0Ew2nrXxwpYQjT0C3/3GVVcXwdSg7cQ5cwj2c2NO4bjEwq2rg7TMVFKFlLZsBn/YNXZLFB7Mt5TZCiPPfmJHYuO169IhwLm+AQuiSlDs4p5D+8LxWCZtsB+fLL3Eerw3jQZ3Hwrdz/2SiP2MA56IH/gDIMXhcEpbzm4Jhh74WTqkU5f1sGZ8ICaFPd9hOAwRsr2GODM/P8YvV+fPxEJiA5UByUqbVLQS6fV5DedogVsIJzojUHna7GV2pxON/gJJNh1LdMofRDm1I4pX5wAbTOPE0Tv1VXAA+hXZQlCS4cqFK3peISapI7N3I8FLSwL8JyaEfHc3YZ+asX7CFtcmq0sR8dori9ADC6dxf5jXppaMsxJ8Frg/RrC1zpPok0jFAb/OSN1elPVUPxo1vo+r YlR1HoXH ru0LnVtMa77WWlPq0xZRUuw97KIzXVgymGkLTBJ+c9cQbVsvjiGXkW3Q/1eMU3ic+runE+FGU2B/qKfuF0rAEPU8TQfjeNU447lEYpfpoo1NGRZyLaXL/tmjSZWVrFtq/YOmgWuyc4vrYdnW+RWoJtGrJl2tS3CtOn/O9HkbYL45cmlweCQDVwQZCECFKwIEpdgfraa4oDyDRlpvImStRdoagE/XpBT1mPWjkXIaririSmAk= 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 Wed, Apr 30, 2025 at 06:14:28AM -0700, Yosry Ahmed wrote: [...] > > + > > + if (!_css_rstat_cpu_trylock(css, cpu, &flags)) { > > > IIUC this trylock will only fail if a BPF program runs in NMI context > and tries to update cgroup stats, interrupting a context that is already > holding the lock (i.e. updating or flushing stats). > Correct (though note that flushing side can be on a different CPU). > How often does this happen in practice tho? Is it worth the complexity? This is about correctness, so even a chance of occurance need the solution. > > I wonder if it's better if we make css_rstat_updated() inherently > lockless instead. > > What if css_rstat_updated() always just adds to a lockless tree, Here I assume you meant lockless list instead of tree. > and we > defer constructing the proper tree to the flushing side? This should > make updates generally faster and avoids locking or disabling interrupts > in the fast path. We essentially push more work to the flushing side. > > We may be able to consolidate some of the code too if all the logic > manipulating the tree is on the flushing side. > > WDYT? Am I missing something here? > Yes this can be done but I don't think we need to tie that to current series. I think we can start with lockless in the nmi context and then iteratively make css_rstat_updated() lockless for all contexts.