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 22364C433F5 for ; Mon, 28 Feb 2022 12:35:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE5108D0002; Mon, 28 Feb 2022 07:35:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A94D68D0001; Mon, 28 Feb 2022 07:35:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 983028D0002; Mon, 28 Feb 2022 07:35:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 873AF8D0001 for ; Mon, 28 Feb 2022 07:35:30 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3C1288249980 for ; Mon, 28 Feb 2022 12:35:30 +0000 (UTC) X-FDA: 79192134420.28.EBA7E31 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf24.hostedemail.com (Postfix) with ESMTP id 90F5018000B for ; Mon, 28 Feb 2022 12:35:29 +0000 (UTC) Date: Mon, 28 Feb 2022 13:35:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1646051727; 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=NrXkZIXCIbcCdTt1MSpZIrgg4yhy+z0slRqeYoIDKJQ=; b=zfPFtUvutLYYHKGpmWQcWje1s6f2f+G6B8+9yNeAZwmQW7kJNPL43+vYWrB3aejmPeGdb5 xP4ZBpfjp2h/ILzvE0WoYqRIl3nrhQyPkwRU1ooZp3C4TywyBL2VJENpXTLPOI2jF4InDn J0F6b8AhkbptW7hr+ABVOY4KcHJYrZzwdSR26BH2ZTrQpdvibthwj0YRMSlgOO3SqvG4yG 5Ps8VMnMejBUqkgBNJOVIVu+baSAWusRHhfcssIi5vAoaBMaq5IHk9Ztp2wFRnD2/9kiAq usISL7szkGNL6DutISpY6xOorqvchmbakdZ7qSH8XdQP6sc5k461pvXHIDoBLw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1646051727; 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=NrXkZIXCIbcCdTt1MSpZIrgg4yhy+z0slRqeYoIDKJQ=; b=siDmoQ6Xa3WguvR8ZjduUL4qXi7hQbJtZxBsk8HnrmRdRn4DpCdBK8kT53PBGqI0tj6Kav va+l7WlflT0jFTCg== From: Sebastian Andrzej Siewior To: Michal Hocko Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Michal =?utf-8?Q?Koutn=C3=BD?= , Peter Zijlstra , Thomas Gleixner , Vladimir Davydov , Waiman Long , Roman Gushchin Subject: Re: [PATCH v5 3/6] mm/memcg: Protect per-CPU counter by disabling preemption on PREEMPT_RT where needed. Message-ID: References: <20220226204144.1008339-1-bigeasy@linutronix.de> <20220226204144.1008339-4-bigeasy@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 90F5018000B X-Stat-Signature: c1xzm5wxpiqihfrdnhxpff6unixzhgff Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=zfPFtUvu; dkim=pass header.d=linutronix.de header.s=2020e header.b=siDmoQ6X; spf=pass (imf24.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-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646051729-822535 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-28 12:23:12 [+0100], Michal Hocko wrote: > On Mon 28-02-22 12:08:40, Sebastian Andrzej Siewior wrote: > > On 2022-02-28 09:05:45 [+0100], Michal Hocko wrote: > > > Acked-by: Michal Hocko > > > > > > TBH I am not a fan of the counter special casing for the debugging > > > enabled warnings but I do not feel strong enough to push you trhough an > > > additional version round. > > > > do you want to get rid of the warnings completely? Since we had the > > check in memcg_stats_lock() it kinda felt useful to add something in > > __memcg_stats_lock() case, too. > > The thing that I dislike is that there is no other way for potential > users of those counters to know these expectations. This is not > documented anywhere so it mostly describes the _current_ state of the > code which might change in the future. We can be more thorough and > document counters wrt. to the context they can be used in which would > make this less of a concern of course. But this can be done on top hence > I do not want to push you for another versions. It is good to have your > current work merged in the next merge window as long as there are no > fallouts and for that it would be good to have it in the linux next and > exposed for some more testing rather than dealing with this deatails. Okay. Then I would suggest then I document the usage context of these counters once things settled down. Now there is no validation at all, so if someone uses the wrong context for a counter and you don't spot it during the review then there will be no warning at runtime. Sebastian