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 B1442C433F5 for ; Mon, 21 Feb 2022 13:18:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E67C88D0002; Mon, 21 Feb 2022 08:18:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E166B8D0001; Mon, 21 Feb 2022 08:18:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDDD28D0002; Mon, 21 Feb 2022 08:18:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id BFA358D0001 for ; Mon, 21 Feb 2022 08:18:29 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7396C181E25B1 for ; Mon, 21 Feb 2022 13:18:29 +0000 (UTC) X-FDA: 79166841138.28.ECE348C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf17.hostedemail.com (Postfix) with ESMTP id D7E684000A for ; Mon, 21 Feb 2022 13:18:28 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 8854C210F0; Mon, 21 Feb 2022 13:18:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1645449507; h=from:from:reply-to: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=aRXcFsOUSSMa2BGcwAaU3jThpHs0aCs0hHkKe3j5Nk0=; b=iSPAuStelADUpXCvEe6gFVGnj6K+QDQusZ4BDFfdwORGpDkOAjfsZiTn85OAbt4uLT9ihu 5K++/pWtAOqwrTi2yYTl10O9i9URTzTtP5pb8q964FMvvCAgqmMRi+3wEmzFgFtfeRhbWQ y0ie2MMVgIl2g2HE25jHlMCQrk115Ng= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 623C613AF2; Mon, 21 Feb 2022 13:18:27 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Ybd6FyORE2KdfwAAMHmgww (envelope-from ); Mon, 21 Feb 2022 13:18:27 +0000 Date: Mon, 21 Feb 2022 14:18:25 +0100 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Sebastian Andrzej Siewior 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: <20220221131825.GA7534@blackbody.suse.cz> References: <20220217094802.3644569-1-bigeasy@linutronix.de> <20220217094802.3644569-4-bigeasy@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=iSPAuSte; spf=pass (imf17.hostedemail.com: domain of mkoutny@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: D7E684000A X-Stat-Signature: g5e9gg1dy5q1sxqsdkurszagqcai8f93 X-HE-Tag: 1645449508-526 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 Mon, Feb 21, 2022 at 12:31:17PM +0100, Sebastian Andrzej Siewior wrote: > What about memcg_rstat_updated()? It does: > > | x = __this_cpu_add_return(stats_updates, abs(val)); > | if (x > MEMCG_CHARGE_BATCH) { > | atomic_add(x / MEMCG_CHARGE_BATCH, &stats_flush_threshold); > | __this_cpu_write(stats_updates, 0); > | } > > The writes to stats_updates can happen from IRQ-context and with > disabled preemption only. So this is not good, right? 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. This could affect freshness of the stats not their accuracy though. HTH, Michal