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 C3C4AC433F5 for ; Mon, 28 Feb 2022 11:23:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F9098D0002; Mon, 28 Feb 2022 06:23:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A7208D0001; Mon, 28 Feb 2022 06:23:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 195318D0002; Mon, 28 Feb 2022 06:23:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 0AE1E8D0001 for ; Mon, 28 Feb 2022 06:23:19 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CEAE9102F for ; Mon, 28 Feb 2022 11:23:18 +0000 (UTC) X-FDA: 79191952476.10.54A2B38 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf28.hostedemail.com (Postfix) with ESMTP id 2927FC0002 for ; Mon, 28 Feb 2022 11:23:18 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D451B1F895; Mon, 28 Feb 2022 11:23:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1646047396; 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=KR6yo3C6hJQk5k7SpkBMoRJDBxwgQp2yNNIt116CbC8=; b=LjHmtuP3WDYlvPgswTQU7/wTCdZoXJ1pFMe8y4EoxX49PehbYAMD7AHzqyREGFBNGmBAqi ELrQuydUDJEL9gAnbxWYbqBjnyq7RHgn/TOd6EYCgpHndNmiXudczQnjR3HjDu9TaRCQhG 0ru55ZKi/CMeP62MvOCMIHLrP15v+ek= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 882A2A3B81; Mon, 28 Feb 2022 11:23:16 +0000 (UTC) Date: Mon, 28 Feb 2022 12:23:12 +0100 From: Michal Hocko To: Sebastian Andrzej Siewior Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , 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=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 2927FC0002 X-Stat-Signature: xncfs9wi1ydzfx9ktny891e4wnrn1773 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LjHmtuP3; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-HE-Tag: 1646047398-590325 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001354, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. -- Michal Hocko SUSE Labs