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 DA29EC35FF1 for ; Fri, 14 Mar 2025 17:38:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 968E7280003; Fri, 14 Mar 2025 13:38:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F11A280001; Fri, 14 Mar 2025 13:38:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79205280003; Fri, 14 Mar 2025 13:38:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 58E8C280001 for ; Fri, 14 Mar 2025 13:38:56 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 74C7E161486 for ; Fri, 14 Mar 2025 17:38:56 +0000 (UTC) X-FDA: 83220867072.10.33FE6A9 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) by imf10.hostedemail.com (Postfix) with ESMTP id A1584C0008 for ; Fri, 14 Mar 2025 17:38:54 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=M0dV2jm6; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741973934; a=rsa-sha256; cv=none; b=mRrt7dY1+pS8Ju5y5JUr5NyaZFaLHdeEOr2TPiSTGDTwFudcm/vLyeGiGNKOz1DJNPoVEg a1f+VEp/0xZjEJX2hZM5+hkHHF4MFbqURohzKvZybkX2rK7Z4rJwX/g40xR5kHItS0LL2H lCyK1cdaFhZXu1uki2O7EHggtIABz2g= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=M0dV2jm6; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.187 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=1741973934; 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=zWi7wol7URKv7PqbpC5ssfeF0V5pQ7aeDMBGL83Sy1M=; b=CikMNrBxPgA40Q7lbktR0pyh7rdDtkIp6+Aa0KUvnM/MCy1Tb4zYk6DSkRSLybrppH8RuB G2jm1qOoQ+n4TbUtIYCynl6G64c7UboC/TYBCUdDG2Ccuq/hnlZA67py6cFpON0R7b3dbw 9f07/ekZ06DZgVBR/rHJxMovbtn3djw= Date: Fri, 14 Mar 2025 10:38:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741973933; 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=zWi7wol7URKv7PqbpC5ssfeF0V5pQ7aeDMBGL83Sy1M=; b=M0dV2jm6zRqcXo2yTvwRlrFd66kFmp3T1EBe0FPhfuk266Yh4xxe3+UXMJ4J8eHGWI6y5j jFWv/LCWTuN3IrOTymNDtnKtrVx3Mfuv7nd1B/yKRn4FgoPAz1hiPT1PdwH/5xl0zqBe5R Sm/sbn6H0xD/tOn8l4cYWTQe1HCTRJs= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Sebastian Andrzej Siewior Cc: Vlastimil Babka , Tejun Heo , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [RFC PATCH 10/10] memcg: no more irq disabling for stock locks Message-ID: <3uyrvm2vvpyplehpbhiroyiebrrpv7hgrv37fuq2vx7yiinfbs@exjiwtjavn52> References: <20250314061511.1308152-1-shakeel.butt@linux.dev> <20250314061511.1308152-11-shakeel.butt@linux.dev> <9e1e3877-55ae-4546-a5c1-08ea730ea638@suse.cz> <20250314115802.DESa-C1z@linutronix.de> <2c62mvfo4726x3ci3sze7u55encoycbbzbaatzslkbhur2dkvd@wlli7wrcjlik> <20250314164234.KHdt_CWt@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: 5shauqdfc8gjfhnsyw51ogj84a8fbxhd X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A1584C0008 X-Rspam-User: X-HE-Tag: 1741973934-29555 X-HE-Meta: U2FsdGVkX1/poZk44K0PnDbmPdvWO9lSTxfuIIrLyqCLS+zwwmAzP1LNVJwvCdn8Cko7PBe68MWJErn/f3O26QrBZcFSOx7c29Kr/lByDB0jrCcCIRWXnfhHLDXptUHjIXPdVgfQbqJ7H5d3fa4pwPVMuxNp3sgZEUq/Mt+e9TJdS2RAzXDAqg5K8lCP7lNbHsG14nNo64kzX9/a01lXsE42eKZkIlokDMw/tEIodxLCUnbgmwOoeGKfqq9busSuxjXJVS+J88s8kibbZyP9OP+LjlNpkFGSFAM7PWIvFd3slJ7Si/pHmK+jBpeL1iPxxHQcakrjnHM0rbuOHhmUBEzEdhujjUEyGyIWhKXUU5alL+EYzH3KcfuCKObAWkQcSyPaLun+kVM2Fp9c8XRg78o/gEQNrhsxTk+/MWuoFjlqEXDbzkSMVwwadOciTZhAmoO4GI9j4PcircqSkSweIroZLNK6cAAkkI0wp02CJhI+xEqGJYhGLazl70C9iPLEaeAPYkUQVzd8a3DeJBoToytQHqQ0J36ctBpktioDvl//PtJMJEAu62VaFjL84+vsdOERhyUGCidXb2nJtwkpGg91w3hb3AAUUgMVvO0dgJSexI3+uRJElicPeiCJMep+UT/dsB7oSb5cc3uefDZdd/NrKvBFue5hFgCU9/GrsdhiZA0/O0fdWpqIvvF+ICbpIg30hdxu/xt8fJW5iPZGxGOCk5/3sjKDZbM6Aldxvz21xk+/TmD0QxvIv/oW5DUdu+UIoiAqYOVkIsx9aDo+iUSgPCY+hZGMWsnT+dI2w+391AqwSODGsKsnrbup0pZcqvSCxELzXOtsB8UDT1t/KRTNrPP73USEFEDUBirYNT012afwH8sCN3MD2agwCq0gVJWNP8ohYyPZXdPfrkfqyXD4MIC5dIh0JviDsVxnqea9tdMP4M4rk5Aageih3CyckaOl/Oar0PlrLwLpg+9 PLqUv1bB AbjY7hWafWnRdAM5Ya0YpEW703dzvEJHSOZPrjrlRWJSSFT0NC4qj2Xho61P8YqJYUUN4wsratJISUlBXSx/Cz4d+u+4LosS4P7ynHGfnMqVJceEcAZbYBuUJwjqM8A5hrJZv2PoiNAVfsVFnntEj0lfYU19/xdpKXi9RkKBD/tHDk5i8XdFoHFR1+A== 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 Fri, Mar 14, 2025 at 10:02:47AM -0700, Shakeel Butt wrote: > On Fri, Mar 14, 2025 at 05:42:34PM +0100, Sebastian Andrzej Siewior wrote: > > On 2025-03-14 08:55:51 [-0700], Shakeel Butt wrote: > > > On Fri, Mar 14, 2025 at 12:58:02PM +0100, Sebastian Andrzej Siewior wrote: > > > > On 2025-03-14 11:54:34 [+0100], Vlastimil Babka wrote: > > > > > On 3/14/25 07:15, Shakeel Butt wrote: > > > > > > Let's switch all memcg_stock locks acquire and release places to not > > > > > > disable and enable irqs. There are two still functions (i.e. > > > > > > mod_objcg_state() and drain_obj_stock) which needs to disable irqs to > > > > > > update the stats on non-RT kernels. For now add a simple wrapper for > > > > > > that functionality. > > > > > > > > > > BTW, which part of __mod_objcg_mlstate() really needs disabled irqs and not > > > > > just preemption? I see it does rcu_read_lock() anyway, which disables > > > > > preemption. Then in __mod_memcg_lruvec_state() we do some __this_cpu_add() > > > > > updates. I think these also are fine with just disabled preemption as they > > > > > are atomic vs irqs (but don't need LOCK prefix to be atomic vs other cpus > > > > > updates). > > > > > > > > __this_cpu_add() is not safe if also used in interrupt context. Some > > > > architectures (not x86) implemented as read, add, write. > > > > this_cpu_add()() does the same but disables interrupts during the > > > > operation. > > > > So __this_cpu_add() should not be used if interrupts are not disabled > > > > and a modification can happen from interrupt context. > > > > > > So, if I use this_cpu_add() instead of __this_cpu_add() in > > > __mod_memcg_state(), __mod_memcg_lruvec_state(), __count_memcg_events() > > > then I can call these functions without disabling interrupts. Also > > > this_cpu_add() does not disable interrupts for x86 and arm64, correct? > > > For x86 and arm64, can I assume that the cost of this_cpu_add() is the > > > same as __this_cpu_add()? > > > > on arm64, __this_cpu_add will "load, add, store". preemptible. > > this_cpu_add() will "disable preemption, atomic-load, add, atomic-store or > > start over with atomic-load. if succeeded enable preemption and move an" > > So, this_cpu_add() on arm64 is not protected against interrupts but is > protected against preemption. We have a following comment in > include/linux/percpu-defs.h. Is this not true anymore? > > /* > * Operations with implied preemption/interrupt protection. These > * operations can be used without worrying about preemption or interrupt. > */ > ... > #define this_cpu_add(pcp, val) __pcpu_size_call(this_cpu_add_, pcp, val) > Just got clarification from Johannes & Tejun that this_cpu_add() is indeed safe against irqs on arm64 as well. Basically arm64 uses loop of Load Exclusive and Store Exclusive instruction to protect against irqs. Defined in __PERCPU_OP_CASE() macro in arch/arm64/include/asm/percpu.h.