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 14325C369D9 for ; Wed, 30 Apr 2025 15:03:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 785DE6B00C9; Wed, 30 Apr 2025 11:03:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70DA06B00CA; Wed, 30 Apr 2025 11:03:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D5C36B00CB; Wed, 30 Apr 2025 11:03:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3CE296B00C9 for ; Wed, 30 Apr 2025 11:03:18 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DA28C1201EC for ; Wed, 30 Apr 2025 15:03:18 +0000 (UTC) X-FDA: 83391028476.17.9111588 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) by imf23.hostedemail.com (Postfix) with ESMTP id 1B34B140016 for ; Wed, 30 Apr 2025 15:03:16 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=GmqBvlf+; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746025397; a=rsa-sha256; cv=none; b=G/DZqHAI3jDkKFK7s8eE8T31riSae3TKYOELbhv2wMvREskAsS481/oNV6FMNeacvwEeSC EGo4aymTXFRzQCsR5FuGAZngsSASohNrmn//K3AfcOwHea0/SqkpW39r8p37+RbW/BwpNb wWZdQRCk4ZF1PtQZQ5AEgBVLLyVyU6s= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=GmqBvlf+; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.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=1746025397; 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=FtTmY7VNaauY8JAzhPRIMcx1YGjVMzAwEwdhfk28sUs=; b=00R9p0HdezNUsnTfPyvjPRWHVwZqTMmrL5t2b2Uz3KTnfYTLMZkkjB+WNtXR+FlNKz3Ajs WHCWqtjhgar+80mjuz+9htOwLfZ+zlUNaW68T+cUpxu5QF3dQ0EDFgGKjRdx704WA88Ndq NmgUS1UsfOPkzRpQAHyohh/K7B22a50= Date: Wed, 30 Apr 2025 08:03:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1746025394; 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=FtTmY7VNaauY8JAzhPRIMcx1YGjVMzAwEwdhfk28sUs=; b=GmqBvlf+HvX3DHUEbaCHIs70ES6Y2F6pCwBPy9hYlXb9hB3Fj9XDAHWU+5l1He2vbKgK8M 21I10XnRsDe5ngHVPySdB8LcM8UvAn0AEnFBjHAW53NF8dHltqooKnIcfGV0nm4SLSQwAp azE0DTPZY+CQsQv3ZV2CiyLtKXKHeT0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Vlastimil Babka Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Sebastian Andrzej Siewior , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team , bpf Subject: Re: [PATCH 2/4] memcg: separate local_trylock for memcg and obj Message-ID: References: <20250429230428.1935619-1-shakeel.butt@linux.dev> <20250429230428.1935619-3-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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1B34B140016 X-Stat-Signature: 75or69cp3pu6ntm5if8jyh7sqxhcaiyd X-HE-Tag: 1746025396-459051 X-HE-Meta: U2FsdGVkX188VK7ZzRhhfPp+T965gacE2aHFM+duXDJojli7EQK9KCbw8n/OYbguNne02Oid55xUzn7zOSCvPhXdhPUR2nEnVWeiQw0fQkcDjFVbCIUaN0eDfwgGer/PocclQN5Cwd7RgOdpDtRyaI+7eZ/pRtGdbW4tyMJMBLsv1T9uCvjOpAiJCm0N5oeA6TnpBtSxEfpyiVdNTzB0IxLSPBta1l000MnZlr7ICl068C8AwLual/64pV0H6VW+lhr6E7yfkNttBCVNg/WRfFX/Taq9ktS+f/IHKL1Z8hF4pIyIyuDZLgRtqlV9BthcP9XlLdEM5xSKx76NfYQtYG5FREU/5cdwc/HG4BCYQoXyKo/Dt1baaZEJnLbtxosEfIxnMtkiKOidycj/i3D+A9fCF7cHmXpFqXlanuUHVe9O8s4aehwvzS9xqRsRGiaqG+lGyg2QKZLuooGF+6lhNEU5vbRQ7n6CPkZG8txh8h+giQo4xmtmiQO3Kpf6CRG6j3S+5Ftaa5iWoxxZe6N7HDXq/RCtqkV/6AwohE7Dmv22x6IiKfkRFM7dttxCBwzOwYMMraaerawiHfplTF+1sMy9qca7swn3yOqYHl+71FV2wAvE2NtVcVUZyZxiMt+39ACOOi8jbd35p8kLQzIjcFipoH8e2NUzHKezrHSE1o+ixLjVOke7Pyh+obBzYKaIzR7OntluIRcVdcuf/zWgjNgDqmoFbkhnmajYHSWQgOIjp1HqVcZOknGuftuKHqv7DqAPyiW567pEW1SO7+jKtMQrGLIDU8Dviaefy+kwEeEW0i+8ujb7nq87aIwuFGdCp6s6LUa2l1t6leF5JccdpBOi2P5dq7aHszDJuuWKFGJBIUNjYtx2F6CyoJ/7MKqI0G3Kd1oOI8P1AOow8Cgj8lsYB9jbwhqeoAHdbsM2CPpPvU2Vv66FBdpqDO+wyvG79S7NTB4oxR7sqX2v6gr osYWxkeM p8EK+1a7KwZ2EXJrRMOJ0Nv9BqmXMNeUDztfx5dpYl9QEe2phqKXDLDYYA3oSdfppgxGj/tiD7inFZMX9Wgl9MVvyp3atwG57FPq9kbMLtgx2UAhRn+4Ds5Ho22Afnw6o25kITXzFpgft43/+eG+Rxpl0z3EO514v3Sgnj4RWibxqJxJ1+SrrPqUSBj8EEGoIzc+UbVW8dTniS9DOePuGCiZMyzc3kflQobX+T6pfU/7EByc= 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 01:42:47PM +0200, Vlastimil Babka wrote: > On 4/30/25 01:04, Shakeel Butt wrote: > > The per-cpu stock_lock protects cached memcg and cached objcg and their > > respective fields. However there is no dependency between these fields > > and it is better to have fine grained separate locks for cached memcg > > and cached objcg. This decoupling of locks allows us to make the memcg > > charge cache and objcg charge cache to be nmi safe independently. > > > > At the moment, memcg charge cache is already nmi safe and this > > decoupling will allow to make memcg charge cache work without disabling > > irqs. > > > > Signed-off-by: Shakeel Butt > > --- > > mm/memcontrol.c | 52 +++++++++++++++++++++++++++---------------------- > > 1 file changed, 29 insertions(+), 23 deletions(-) > > > @@ -1883,19 +1885,22 @@ static void drain_local_stock(struct work_struct *dummy) > > struct memcg_stock_pcp *stock; > > unsigned long flags; > > > > - /* > > - * The only protection from cpu hotplug (memcg_hotplug_cpu_dead) vs. > > - * drain_stock races is that we always operate on local CPU stock > > - * here with IRQ disabled > > - */ > > - local_lock_irqsave(&memcg_stock.stock_lock, flags); > > + if (WARN_ONCE(!in_task(), "drain in non-task context")) > > + return; > > > > + preempt_disable(); > > stock = this_cpu_ptr(&memcg_stock); > > + > > + local_lock_irqsave(&memcg_stock.obj_lock, flags); > > drain_obj_stock(stock); > > + local_unlock_irqrestore(&memcg_stock.obj_lock, flags); > > + > > + local_lock_irqsave(&memcg_stock.memcg_lock, flags); > > drain_stock_fully(stock); > > - clear_bit(FLUSHING_CACHED_CHARGE, &stock->flags); > > + local_unlock_irqrestore(&memcg_stock.memcg_lock, flags); > > > > - local_unlock_irqrestore(&memcg_stock.stock_lock, flags); > > + clear_bit(FLUSHING_CACHED_CHARGE, &stock->flags); > > + preempt_enable(); > > This usage of preempt_disable() looks rather weird and makes RT unhappy as > the local lock is a mutex, so it gives you this: > > BUG: sleeping function called from invalid context at > kernel/locking/spinlock_rt.c:48 > > I know the next patch removes it again but for bisectability purposes it > should be avoided. Instead of preempt_disable() we can extend the local lock > scope here? > Indeed and thanks for the suggestion, will fix in v2.