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 A081AC282EC for ; Fri, 14 Mar 2025 17:03:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDB7C280002; Fri, 14 Mar 2025 13:03:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8C95280001; Fri, 14 Mar 2025 13:03:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5276280002; Fri, 14 Mar 2025 13:03:00 -0400 (EDT) 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 96AE0280001 for ; Fri, 14 Mar 2025 13:03:00 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4E3FA81444 for ; Fri, 14 Mar 2025 17:03:00 +0000 (UTC) X-FDA: 83220776520.12.8856EBA Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180]) by imf25.hostedemail.com (Postfix) with ESMTP id 56B47A002C for ; Fri, 14 Mar 2025 17:02:58 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="LV7/dTsn"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741971778; a=rsa-sha256; cv=none; b=5yUTw3B6jPWkKfFaglKmcDpSVz4Di64BHVt4dRNaaMqcaPCY2DxCb/36lTCnvyVp8hA69x PqrzKeNYEoCB4jWkrVtBTrsZXx3T9Gql1XvM0DTskpmKN1ofoePZ3AFEVcFGG6ag9fpflk mlzqIlFHNH8psquafNp7o9U9N6HiMuI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="LV7/dTsn"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf25.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.180 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=1741971778; 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=k0GnPyoWjWRYzY+y3ddgehCFP4QTAT7dOgiK5PiqKgc=; b=FKC1FSx7mK1Bsp6AaYDcdcjMXAgwtZ4XwaWWnAnZsVRKyRnEl4rsQhhvAwrzI2YAxMuGkm NjfmeCbbFMNxOvO5L4Xh9GNQijG94CZN4RDrz06zVsYz8RcigJAfokXxgcNw+fh7QIFd8N Z4iYf2xNVypx/vXO/kZTdBmgIEew03A= Date: Fri, 14 Mar 2025 10:02:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741971776; 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=k0GnPyoWjWRYzY+y3ddgehCFP4QTAT7dOgiK5PiqKgc=; b=LV7/dTsnenhzwKr0M/PS/0cxdyos5YYdZQgHRKrtlCWJhv3M4NeowUNX+t3h4pJlTNSbz/ gaJWfg20JCFVntxvYvxkE06UPuBBOPGBNoX2uRALuImhBrhdU/Gn3lkVtpRZdGf/JXn4FI /QgfEys4H6NEzg6lPXxU9aqq4tgINbs= 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 , 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: 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: <20250314164234.KHdt_CWt@linutronix.de> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 56B47A002C X-Stat-Signature: rtp7fmoigmisq6fwmji7x87frruoxofa X-Rspamd-Server: rspam06 X-HE-Tag: 1741971778-121563 X-HE-Meta: U2FsdGVkX18fFmgealPo5XWZ26F4LcEuMZLIv3gXRPeei3TSZJEmdQbzGG4AVK7htOZFuC4wsrLDqSA8t0bkDMEzcKA4gglFZDrXgALb9wD/mSjkTPhlCvftzDrUGf8zElQghV5PA7bZTJQ6bsNVob4gvICK9S/aKtp4jJk3VyCAYeuwUte0iv6Cb/1kZhrrTS7HPrjX77VQRjmxOLlHQU54ytmZd52o6IV8HX6HqwJIRqkQO0odP1qJqJu25geb/enODu+GgcxzDz0bf8ThCBGfV9QkVnXHZO9koy+5bUOicw6cMIfc525cFjk/g/ObN7IOx4VpI4rFT9LfdckR2kMy773X5fYwDTZBYqygQCrJ+pqiNYVBcs61ix64rMUW83pRtkz/S8BAWaC/ZJ7CBa++/gse9+eC9LeL6rhc1H/pJAEGFohMoNzayT4mNXfnzFNfOZWWWGk+FKnZjzLX7AWhNnibl11PkjCEVuwvZ8CETeVilrmjNMwfXjoVqPMpuJfznqNQVPj6wnGFBT++uxpPCsmoSUr7ZvEgu7tHtsTdSwDIkiWT3FCbJwchxGZG0U4gscdrxnwlzUzPNDW5QorD9VzmcSH0pKm8Ju8g4gtE3EbV9MkRDoGymFL9yYNuPqqQos/Pn7e8BCqbNzF3EpNb0d/BEbrukZqUG1l+Tvb+n2+GMyUbDswQl8yyY+xtrwMupYn1A+MtOc5NJVxk5duoWqzlv/sKwjxVKRYh3xrc7j1rYZLgL0bPjuNQjbUcC2hpXXHQ9jkxGkp6k8ccC0+pm2m9q0C6GK7diiGO8u7bs8KJey4QhiuZ/UlSJDhDh7ejn91sUP6ZKTvgIAm71PJMQBMiDJ60PAfOiMucipvsjxqljkFgon3OvIVrNqG6hOEhJkhWSzAp/vsXz+bWEF552qohvYdIAqR/SM5tYGWRAPRnJlFsPCOR/M9A8lMD8Vw3rJ0OwSSoY/oQv74 uFE28jQh y3vqFswnMzFeD549UDjlwcNGit2jbriEfjl2f7ExnHEPxJ8GVJ1Lhq8/5Cpasd/tqWoEkl5jKKfXKCmjoLFHe+Q4m0a9Y06Wc+01lda5c8aSmshPakVs7/16lVGhVf3c4A+V40eEnSlnCFt7jZx7SwrNVa5om7ktuswV/Rn0ugo6/583Tq5YL/Wj3Rw== 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 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) > > so no, this is not the same. On x86 it is possible to increment a memory > value directly with one opcode so you get preempted either before or > after that operation. > > Sebastian