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 979A5C433F5 for ; Wed, 15 Dec 2021 18:44:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C58F6B0072; Wed, 15 Dec 2021 13:44:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 075906B0073; Wed, 15 Dec 2021 13:44:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7E4E6B0074; Wed, 15 Dec 2021 13:44:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay034.a.hostedemail.com [64.99.140.34]) by kanga.kvack.org (Postfix) with ESMTP id DAAA46B0072 for ; Wed, 15 Dec 2021 13:44:13 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id A8D5880730 for ; Wed, 15 Dec 2021 18:44:03 +0000 (UTC) X-FDA: 78920903166.03.616E899 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf31.hostedemail.com (Postfix) with ESMTP id CDCB620014 for ; Wed, 15 Dec 2021 18:43:56 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D24371F3CC; Wed, 15 Dec 2021 18:44:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1639593841; 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=NWqD+PcCuxR8HDxLdpgeitQDnhGffUIL9j/CCfmjTsM=; b=ZrtZuZL9p+UI1aJNPgIfrBv5AA1n9CG6VLC82bQzhuhvW7kETDDJ0FtNiqFx7Cufw+EZn7 QMszsvkFZ+2lBhW1DRQUbdIy1BOnr7EIedb4HK+T+H3BUi/X41gWGwT9SUgAQiem8cRx6Q OCtF40bavtOsWRDwyGAdw85RjFdlFMs= 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 969CCA3B84; Wed, 15 Dec 2021 18:44:01 +0000 (UTC) Date: Wed, 15 Dec 2021 19:44:00 +0100 From: Michal Hocko To: Sebastian Andrzej Siewior Cc: Johannes Weiner , cgroups@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Thomas Gleixner , Vladimir Davydov , Waiman Long Subject: Re: [PATCH] mm/memcontrol: Disable on PREEMPT_RT Message-ID: References: <20211207155208.eyre5svucpg7krxe@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ZrtZuZL9; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf31.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CDCB620014 X-Stat-Signature: xxcech1kwt66bytsx6n7xaeo1qybueph X-HE-Tag: 1639593836-452436 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 Wed 15-12-21 18:13:40, Sebastian Andrzej Siewior wrote: > On 2021-12-15 17:56:03 [+0100], Michal Hocko wrote: > > On Wed 15-12-21 17:47:54, Sebastian Andrzej Siewior wrote: > > > On 2021-12-13 11:08:26 [+0100], Michal Hocko wrote: > > > > On Fri 10-12-21 16:22:01, Sebastian Andrzej Siewior wrote: > > > > [...] > > > > I am sorry but I didn't get to read and digest the rest of the message > > > > yet. Let me just point out this > > > > > > > > > The problematic part here is mem_cgroup_tree_per_node::lock which can > > > > > not be acquired with disabled interrupts on PREEMPT_RT. The "locking > > > > > scope" is not always clear to me. Also, if it is _just_ the counter, > > > > > then we might solve this differently. > > > > > > > > I do not think you should be losing sleep over soft limit reclaim. This > > > > is certainly not something to be used for RT workloads and rather than > > > > touching that code I think it makes some sense to simply disallow soft > > > > limit with RT enabled (i.e. do not allow to set any soft limit). > > > > > > Okay. So instead of disabling it entirely you suggest I should take > > > another stab at it? Okay. Disabling softlimit, where should I start with > > > it? Should mem_cgroup_write() for RES_SOFT_LIMIT always return an error > > > or something else? > > > > Yeah, I would just return an error for RT configuration. If we ever need > > to implement that behavior for RT then we can look at specific fixes. > > Okay. What do I gain by doing this / how do I test this? Is running > tools/testing/selftests/cgroup/test_*mem* sufficient to test all corner > cases here? I am not fully aware of all the tests but my point is that if the soft limit is not configured then there are no soft limit tree manipulations ever happening and therefore the code is effectivelly dead. Is this sufficient for the RT patchset to ignore the RT incompatible parts? -- Michal Hocko SUSE Labs