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 17710C433F5 for ; Wed, 15 Dec 2021 17:14:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87DC56B0071; Wed, 15 Dec 2021 12:13:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 82CC76B0073; Wed, 15 Dec 2021 12:13:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F4B36B0074; Wed, 15 Dec 2021 12:13:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay038.a.hostedemail.com [64.99.140.38]) by kanga.kvack.org (Postfix) with ESMTP id 6320A6B0071 for ; Wed, 15 Dec 2021 12:13:54 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 31AE480639 for ; Wed, 15 Dec 2021 17:13:44 +0000 (UTC) X-FDA: 78920675568.02.4688BDD Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf08.hostedemail.com (Postfix) with ESMTP id 04F31160010 for ; Wed, 15 Dec 2021 17:13:39 +0000 (UTC) Date: Wed, 15 Dec 2021 18:13:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1639588421; 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=jYXjzbGZlnN964PjJtzgEeX8RXqMVqwrS5n7/IuOGFI=; b=REqxSx+V31su26fCsE584O65uicmLycV3UA7QCYU9fdpth3uBkeQoRi4uJDeJLc4JUvAtD +PHYJDuMxpxJGiz2JkppXqJZcskLdO4iXoeTIJt/ImE8S72gp2dAA3Cx0sGcR6kGIxStY2 +52K2rbXYrTAxMSNFYImMHK6G9rpOttoQvCxrLbhK/w7cvjU4ao8Yi3HVfoawP7Ah6/PDg nITGvxnemLqPRUlENkSdgr6gzPfPnb5FtV3qPfhrHYXdmE6/4xp/LYaaNoA8VE/+k5EVX1 +Iwcc+fsW8iKf1R7Q8M/Cxu6iZ9tw48srCmxB4wUd73qxqorCjBGXjGqOFJ6WA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1639588421; 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=jYXjzbGZlnN964PjJtzgEeX8RXqMVqwrS5n7/IuOGFI=; b=QJ4AOPazmGLlU6Mdv7IO0XBCvO5u84k/9ccp0EH3VnFLVEfxqOu8XJY74BDcJ7iQQ8AYPB RsymUKCJvMZ/QrAg== From: Sebastian Andrzej Siewior To: Michal Hocko 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=utf-8 Content-Disposition: inline In-Reply-To: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=REqxSx+V; dkim=pass header.d=linutronix.de header.s=2020e header.b=QJ4AOPaz; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf08.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 04F31160010 X-Stat-Signature: f68674g3bwsxh7pm179rg375msui7mef X-HE-Tag: 1639588419-388879 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 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? > Thanks! Thank you ;) Sebastian