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 84859C433F5 for ; Thu, 23 Dec 2021 07:34:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1032A6B0072; Thu, 23 Dec 2021 02:34:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B2906B0073; Thu, 23 Dec 2021 02:34:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBC006B0074; Thu, 23 Dec 2021 02:34:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id D8AA86B0072 for ; Thu, 23 Dec 2021 02:34:23 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 951F389930 for ; Thu, 23 Dec 2021 07:34:23 +0000 (UTC) X-FDA: 78948246006.18.D928518 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf06.hostedemail.com (Postfix) with ESMTP id CFA5618002A for ; Thu, 23 Dec 2021 07:34:21 +0000 (UTC) Date: Thu, 23 Dec 2021 08:34:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1640244860; 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=2tROn/paYAmSCszbEQd9FE7LVsYuR0niFVGpk5kB1Vc=; b=JDOnNXQOT4ssAGisSFSsvY9e1Q6YTYi00Qq+6vYuW3ThqePBOgTrEOH/fgxFwSKT29vt/D 0g9chxDZWq3m9FXHLX4B/ESKKdSbtZtRZlX31FPg++h9xk5k+5HFx2LibP0NpLUJO/FzBr 45eJAym2zSABM7IpHTCqWSzwDATiJjor/xMYDB5jd7pGpuwGVYh7WAqpopSYc+G7bZn66i IVs/PS1cqdn0cLxFiWbOXoL+lWwTUyTep1px+ObysoBksu4U9e5bgq1v/Pna82NGIuDFGn ApacJM6IPUb49H22HezjtWUkvSroB/kTOWlsJihyxWuAhn9NeSfW2/sQoPnRjA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1640244860; 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=2tROn/paYAmSCszbEQd9FE7LVsYuR0niFVGpk5kB1Vc=; b=Mm3d+/SVvo6rhIseKTHwy0x8jQJq3e4gfeY6H9DKufJ8hvp9D7R5wQcESugYMjceGu47U1 G4HcFy1ma4KE+pCA== From: Sebastian Andrzej Siewior To: Waiman Long Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Thomas Gleixner , Peter Zijlstra Subject: Re: [RFC PATCH 1/3] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT Message-ID: References: <20211222114111.2206248-1-bigeasy@linutronix.de> <20211222114111.2206248-2-bigeasy@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CFA5618002A X-Stat-Signature: o3upb4bhic6sdynmz4p8pu1ea95bgg6j Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=JDOnNXQO; dkim=pass header.d=linutronix.de header.s=2020e header.b="Mm3d+/SV"; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf06.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de X-HE-Tag: 1640244861-854577 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: On 2021-12-22 21:31:36 [-0500], Waiman Long wrote: > On 12/22/21 06:41, Sebastian Andrzej Siewior wrote: > > The per-CPU counter are modified with the non-atomic modifier. The > > consistency is ensure by disabling interrupts for the update. > > This breaks on PREEMPT_RT because some sections additionally > > acquire a spinlock_t lock (which becomes sleeping and must not be > > acquired with disabled interrupts). Another problem is that > > mem_cgroup_swapout() expects to be invoked with disabled interrupts > > because the caller has to acquire a spinlock_t which is acquired with > > disabled interrupts. Since spinlock_t never disables interrupts on > > PREEMPT_RT the interrupts are never disabled at this point. > > > > The code is never called from in_irq() context on PREEMPT_RT therefore > > How do you guarantee that these percpu update functions won't be called in > in_irq() context for PREEMPT_RT? Do you think we should add a > WARN_ON_ONCE(in_irq()) just to be sure? There are no invocations to the memory allocator (neither malloc() nor free()) on RT and the memory allocator itself (SLUB and the page-allocator so both) has sleeping locks. That means invocations in_atomic() are bad. All interrupt handler are force-threaded. Those which are not (like timer, per-CPU interrupts or those which explicitly asked not to be force threaded) are limited in their doing as they can't invoke anything that has a sleeping lock. Lockdep or CONFIG_DEBUG_ATOMIC_SLEEP will yell here. The other counter are protected the same way, see c68ed7945701a ("mm/vmstat: protect per cpu variables with preempt disable on RT") > Cheers, > Longman Sebastian From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Andrzej Siewior Subject: Re: [RFC PATCH 1/3] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT Date: Thu, 23 Dec 2021 08:34:19 +0100 Message-ID: References: <20211222114111.2206248-1-bigeasy@linutronix.de> <20211222114111.2206248-2-bigeasy@linutronix.de> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1640244860; 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=2tROn/paYAmSCszbEQd9FE7LVsYuR0niFVGpk5kB1Vc=; b=JDOnNXQOT4ssAGisSFSsvY9e1Q6YTYi00Qq+6vYuW3ThqePBOgTrEOH/fgxFwSKT29vt/D 0g9chxDZWq3m9FXHLX4B/ESKKdSbtZtRZlX31FPg++h9xk5k+5HFx2LibP0NpLUJO/FzBr 45eJAym2zSABM7IpHTCqWSzwDATiJjor/xMYDB5jd7pGpuwGVYh7WAqpopSYc+G7bZn66i IVs/PS1cqdn0cLxFiWbOXoL+lWwTUyTep1px+ObysoBksu4U9e5bgq1v/Pna82NGIuDFGn ApacJM6IPUb49H22HezjtWUkvSroB/kTOWlsJihyxWuAhn9NeSfW2/sQoPnRjA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1640244860; 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=2tROn/paYAmSCszbEQd9FE7LVsYuR0niFVGpk5kB1Vc=; b=Mm3d+/SVvo6rhIseKTHwy0x8jQJq3e4gfeY6H9DKufJ8hvp9D7R5wQcESugYMjceGu47U1 G4HcFy1ma4KE+pCA== Content-Disposition: inline In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Waiman Long Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Thomas Gleixner , Peter Zijlstra On 2021-12-22 21:31:36 [-0500], Waiman Long wrote: > On 12/22/21 06:41, Sebastian Andrzej Siewior wrote: > > The per-CPU counter are modified with the non-atomic modifier. The > > consistency is ensure by disabling interrupts for the update. > > This breaks on PREEMPT_RT because some sections additionally > > acquire a spinlock_t lock (which becomes sleeping and must not be > > acquired with disabled interrupts). Another problem is that > > mem_cgroup_swapout() expects to be invoked with disabled interrupts > > because the caller has to acquire a spinlock_t which is acquired with > > disabled interrupts. Since spinlock_t never disables interrupts on > > PREEMPT_RT the interrupts are never disabled at this point. > > > > The code is never called from in_irq() context on PREEMPT_RT therefore > > How do you guarantee that these percpu update functions won't be called in > in_irq() context for PREEMPT_RT? Do you think we should add a > WARN_ON_ONCE(in_irq()) just to be sure? There are no invocations to the memory allocator (neither malloc() nor free()) on RT and the memory allocator itself (SLUB and the page-allocator so both) has sleeping locks. That means invocations in_atomic() are bad. All interrupt handler are force-threaded. Those which are not (like timer, per-CPU interrupts or those which explicitly asked not to be force threaded) are limited in their doing as they can't invoke anything that has a sleeping lock. Lockdep or CONFIG_DEBUG_ATOMIC_SLEEP will yell here. The other counter are protected the same way, see c68ed7945701a ("mm/vmstat: protect per cpu variables with preempt disable on RT") > Cheers, > Longman Sebastian