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 9F7C7C433F5 for ; Mon, 21 Feb 2022 13:58:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A5868D0003; Mon, 21 Feb 2022 08:58:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 054658D0001; Mon, 21 Feb 2022 08:58:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5E088D0003; Mon, 21 Feb 2022 08:58:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id DA6C98D0001 for ; Mon, 21 Feb 2022 08:58:38 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 97980853EB for ; Mon, 21 Feb 2022 13:58:38 +0000 (UTC) X-FDA: 79166942316.16.019D067 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf10.hostedemail.com (Postfix) with ESMTP id EFA62C0002 for ; Mon, 21 Feb 2022 13:58:37 +0000 (UTC) Date: Mon, 21 Feb 2022 14:58:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1645451915; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iitq/hbofHwFVa3nea7jsMf/rgjsnN6retKs9evBkAw=; b=qPEhuQ2CmF6oV7BGpiRhqhV00ivvDd2117OATOQJvxQ5UryEGmiFX8ty1T7Dq6VmLrqJam lZt17G/4o1+vEeoGKt32e/VmZKgo72F+dtG6OeGzdmRnIfPVZDW22HBXAotvv+yDL6+tSf KUjgff080D0UbvvtEAL3d8NcBBfJX6Nzp22r+cD6Ly33BjABwv8ZVZbTJc24LhxlcxKRqI Xmxq1NNghkrdWc0nT/WA8M6h5pK1RS2ImvWPaONdlEhViLprTVZaAeEXRO9bbupwJCNPjY arUW2yF590khxdSvX4ftEo5oG5qX2UKhPK3d/e8A4I+DHRxE3dqJB4LMGCQfZg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1645451915; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iitq/hbofHwFVa3nea7jsMf/rgjsnN6retKs9evBkAw=; b=F+r+sm5WhlyUnRW5yuWA/mA7JSWd4B5U8tpnt6zrh5Hs4EU8B26lPuR9+TNU7mrc6Bvc+n lzqOS2tV/KjihuAQ== From: Sebastian Andrzej Siewior To: Michal =?utf-8?Q?Koutn=C3=BD?= Cc: Shakeel Butt , Cgroups , Linux MM , Andrew Morton , Johannes Weiner , Michal Hocko , Peter Zijlstra , Thomas Gleixner , Vladimir Davydov , Waiman Long , Roman Gushchin Subject: Re: [PATCH v3 3/5] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT where needed. Message-ID: References: <20220217094802.3644569-1-bigeasy@linutronix.de> <20220217094802.3644569-4-bigeasy@linutronix.de> <20220221131825.GA7534@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20220221131825.GA7534@blackbody.suse.cz> X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=qPEhuQ2C; dkim=pass header.d=linutronix.de header.s=2020e header.b=F+r+sm5W; spf=pass (imf10.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: EFA62C0002 X-Stat-Signature: r7a9dxghqc65rnabc8x6oanne9qgieha X-HE-Tag: 1645451917-939427 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 2022-02-21 14:18:25 [+0100], Michal Koutn=C3=BD wrote: > On Mon, Feb 21, 2022 at 12:31:17PM +0100, Sebastian Andrzej Siewior wrote: > > What about memcg_rstat_updated()? It does: > >=20 > > | x =3D __this_cpu_add_return(stats_updates, abs(val)); > > | if (x > MEMCG_CHARGE_BATCH) { > > | atomic_add(x / MEMCG_CHARGE_BATCH, &stats_flush_thres= hold); > > | __this_cpu_write(stats_updates, 0); > > | } > >=20 > > The writes to stats_updates can happen from IRQ-context and with > > disabled preemption only. So this is not good, right? >=20 > These counters serve as a hint for aggregating per-cpu per-cgroup stats. > If they were systematically mis-updated, it could manifest by > missing "refresh signal" from the given CPU. OTOH, this lagging is also > meant to by limited by elapsed time thanks to periodic flushing. >=20 > This could affect freshness of the stats not their accuracy though. Oki. Then let me update the code as suggested and ignore this case since it is nothing to worry about. > HTH, > Michal Sebastian