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 D9BA4C5DF62 for ; Tue, 25 Jan 2022 23:21:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEC126B0075; Tue, 25 Jan 2022 18:21:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E72A96B007B; Tue, 25 Jan 2022 18:21:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D12D56B007D; Tue, 25 Jan 2022 18:21:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id BAD8C6B0075 for ; Tue, 25 Jan 2022 18:21:52 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6A93E8249980 for ; Tue, 25 Jan 2022 23:21:52 +0000 (UTC) X-FDA: 79070384064.04.FE298A4 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf29.hostedemail.com (Postfix) with ESMTP id 8799B120007 for ; Tue, 25 Jan 2022 23:21:51 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 85F33B81AC6; Tue, 25 Jan 2022 23:21:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE92DC340E0; Tue, 25 Jan 2022 23:21:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1643152908; bh=Os2MWz5br1ib2WiO76xCA8LnZuVKJFmC7RaP9N/4r0o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=yfnDC4j/A3Ze/Yu/Lo5vpOBBSb7WGzqzIQfb9aBKBYXUanxENNOYdhS5qgb+Snw2a Oo1sOfxKasHmBVZuza4/zG7vu2H3IWuBcYnNK9ooYWsgLOX359S4eIfxKjNvLsWJd6 YIUFWvRtN68ay6Si4EByHUpFRiDgoz0U8tfpUMss= Date: Tue, 25 Jan 2022 15:21:46 -0800 From: Andrew Morton To: Sebastian Andrzej Siewior Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Michal Hocko , Michal =?ISO-8859-1?Q?Koutn=FD?= , Peter Zijlstra , Thomas Gleixner , Vladimir Davydov , Waiman Long Subject: Re: [PATCH 0/4] mm/memcg: Address PREEMPT_RT problems instead of disabling it. Message-Id: <20220125152146.d7e25afe3b8a6807df6fee3f@linux-foundation.org> In-Reply-To: <20220125164337.2071854-1-bigeasy@linutronix.de> References: <20220125164337.2071854-1-bigeasy@linutronix.de> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: n1nkh3gx4i1rtmmjbpfsscxurdfupuxp X-Rspam-User: nil Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="yfnDC4j/"; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8799B120007 X-HE-Tag: 1643152911-640014 X-Bogosity: Ham, tests=bogofilter, spamicity=0.010314, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 25 Jan 2022 17:43:33 +0100 Sebastian Andrzej Siewior wrote: > Hi, > > this series is a follow up to the initial RFC > https://lore.kernel.org/all/20211222114111.2206248-1-bigeasy@linutronix.de > > and aims to enable MEMCG for PREEMPT_RT instead of disabling it. > > where it has been suggested that I should try again with memcg instead > of simply disabling it. > > Changes since the RFC: > - cgroup.event_control / memory.soft_limit_in_bytes is disabled on > PREEMPT_RT. It is a deprecated v1 feature. Fixing the signal path is > not worth it. > > - The updates to per-CPU counters are usually synchronised by disabling > interrupts. There are a few spots where assumption about disabled > interrupts are not true on PREEMPT_RT and therefore preemption is > disabled. This is okay since the counter are never written from > in_irq() context. > > Patch #2 deals with the counters. > > Patch #3 is a follow up to > https://lkml.kernel.org/r/20211214144412.447035-1-longman@redhat.com > > Patch #4 restricts the task_obj usage to !PREEMPTION kernels. Based on > the numbers in > https://lore.kernel.org/all/YdX+INO9gQje6d0S@linutronix.de This isn't a terribly useful [0/n], sorry. It would be better to have something self-contained which doesn't require that the reader chase down increasingly old links and figure out what changed during successive iterations. > I tested them on CONFIG_PREEMPT_NONE + CONFIG_PREEMPT_RT with the > tools/testing/selftests/cgroup/* tests. It looked good except for the > following (which was also there before the patches): > - test_kmem sometimes complained about: > not ok 2 test_kmem_memcg_deletion Is this a new issue? Does this happen with these patches when CONFIG_PREEMPT_RT=n? > - test_memcontrol complained always about > not ok 3 test_memcg_min > not ok 4 test_memcg_low > and did not finish. Similarly, is this caused by these patches? Is it only triggered under preempt_rt? > - lockdep complains were triggered by test_core and test_freezer (both > had to run): Ditto.