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 8A830C25B74 for ; Sat, 25 May 2024 01:04:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A368A6B0085; Fri, 24 May 2024 21:04:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E1A46B008A; Fri, 24 May 2024 21:04:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 881AD6B008C; Fri, 24 May 2024 21:04:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 651976B0085 for ; Fri, 24 May 2024 21:04:14 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D65D01608D0 for ; Sat, 25 May 2024 01:04:13 +0000 (UTC) X-FDA: 82155121986.18.5CF2BC6 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) by imf02.hostedemail.com (Postfix) with ESMTP id C0EBB8000C for ; Sat, 25 May 2024 01:04:09 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FAozuyjN; spf=pass (imf02.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716599051; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ufi9TD8HsXQKxKXjR9qMrAehcd/b8jx9bHHV6cnAIGs=; b=x4Fxs9Mnqu8U6+UjyYPjRrQ9Uep2ajhWn5/6Jx6b3iATOQTCjqPz651rjIapW0aW8xiVZv kwKIxV3xQPN5T9o+DPocr2niyHGC3Z9Xpf5UqJnyz3BK0I2/iVzsJjzqYaiAeW3c6aD2u2 J+a1N0G9v/bz5TPnsB+OW2zjogkjcBE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FAozuyjN; spf=pass (imf02.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.171 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716599051; a=rsa-sha256; cv=none; b=jsJdn7SQ6Q7fv00fgnfxKD2sKfFcU0L1UKfehrbVId6Qu0RH/rQ2gE9QE6x6FeNzZHOQA2 BPGaNHTHxkBchtsPcnyoe7BYuBBOfDMuKUidqy8oh03pIyf0oHB8i8uGJiKNL0nqhl3DWe RwTgdLhWe/96JGmVmplAkqdTArzR0Lg= X-Envelope-To: mhocko@suse.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1716599044; 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=ufi9TD8HsXQKxKXjR9qMrAehcd/b8jx9bHHV6cnAIGs=; b=FAozuyjNwmDcmvjDO8knfuEz9FRgwtkTtXUahBfGyV5svhvezy3006+ewkyP1JVCbc8I+1 47Yhcu0cWRsIM5iAce6BYCcFf4UIjDLZjbhxQyVtLAtC09rtRHAgLxLNJ49I948Q6S3Oau WTMU0OQKC9LNSqFeskI5hKP6CX++8EE= X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: muchun.song@linux.dev X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: shakeel.butt@linux.dev X-Envelope-To: willy@infradead.org X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-kernel@vger.kernel.org Date: Fri, 24 May 2024 18:03:58 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Michal Hocko Cc: Andrew Morton , Muchun Song , Johannes Weiner , Shakeel Butt , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH rfc 6/9] mm: memcg: move cgroup v1 oom handling code into memcontrol-v1.c Message-ID: References: <20240509034138.2207186-1-roman.gushchin@linux.dev> <20240509034138.2207186-7-roman.gushchin@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C0EBB8000C X-Stat-Signature: caegrocc4npny39p6n66m3x5as1gpbox X-Rspam-User: X-HE-Tag: 1716599049-114098 X-HE-Meta: U2FsdGVkX1+HAhBmLt3WZiTS5nZukSsOXQN7G2oVzffcKMbZkdA4uCoP7nWcE17Kwm5OAJsrtI8Eawmr55w/Y6nOvfrQrKVhAiVGvxmmpPd07p+HE4jazABc0F92NPQ702LDYiTFnZ8zLWjwU2fE1GvOrq3eTJWK8jT1+VWr4SnwI5mqQiYbNTUXQBcK7oQqgdLurIc/ysoBxhq71Jz4bxoBpka9M2StL8t2JBaQf/8/vta9YeVmGlcSb6Z6Fb5InR4ZRHImNaFbjCkX8nogBeBAoRmPt8z6acT9okGqqAPSdrLMSggETZ/qnMrQyMy371wDQfK+WvrcazfnQl+YVuy08hmV0zYrTKEjn3/tDpPqBDOCQ+ddATxrfbNFqbf6a3SLI+cavq+pgS0hclqOiy6AYZQY5Bpa+ZoQw5CDPN6Ao/FFMNPKoMN9bJXhs9Po+G/QbbprH7pqtDME1h+jiZO1v9C8k0jJRuMuu6+JspeK41+WqD1dgoKOgujVa9HdHqerMGv41WW6i6h8C8AO8GSs7GsvaSSHVe31nbhCgrsjYZq5Txv9bJczLjP+jNtuZ9HPhJ9FGV9OV3Zs1dhahnELx2fq6dribjZKZwh6+6yGtItyshKfMmPd+4iMUbXWfq/JcUcBL4qXhojhYAB1ld5abChvW4L3nZff9vaQyW2XL4Uo07KHpMHT45qYZtpOB2QrwV2Pfc4epdp257BrI6YrsE6b5xE6e8Cvnexc8+cI6IFEQ/CPZc1U64BhhSB6r0yulS7boLrPm8lH0Mo0YqzPTSj0BZ+4xjmzrQeQb1mBv/6TgENjaumNSgTUtTJze1oh2JUjGKcS7e1iGJxQ3EEBhuxQs7fE+1bL03oIlC/Cr7v+qXcXJMGNQES/OfwVft7nh3plmUBze6KKAFKmR58xUF7PfcRvg3Pmb3ELLhvl5Gx9YKnoNOT2tPjsn00NShMayTKzRCjHt8sisCI WfFtB7tk mg3XqFzggPOVyDYnQ9knziif+WeKJWYuZUUzwwVYqPtwGIE4yeCKUALxB3nSZs2f0GZUc6w3z4y8lA64ip1dGagI2jQ== 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: List-Subscribe: List-Unsubscribe: On Fri, May 10, 2024 at 03:26:35PM +0200, Michal Hocko wrote: > On Wed 08-05-24 20:41:35, Roman Gushchin wrote: > [...] > > @@ -1747,106 +1623,14 @@ static bool mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order) > > > > memcg_memory_event(memcg, MEMCG_OOM); > > > > - /* > > - * We are in the middle of the charge context here, so we > > - * don't want to block when potentially sitting on a callstack > > - * that holds all kinds of filesystem and mm locks. > > - * > > - * cgroup1 allows disabling the OOM killer and waiting for outside > > - * handling until the charge can succeed; remember the context and put > > - * the task to sleep at the end of the page fault when all locks are > > - * released. > > - * > > - * On the other hand, in-kernel OOM killer allows for an async victim > > - * memory reclaim (oom_reaper) and that means that we are not solely > > - * relying on the oom victim to make a forward progress and we can > > - * invoke the oom killer here. > > - * > > - * Please note that mem_cgroup_out_of_memory might fail to find a > > - * victim and then we have to bail out from the charge path. > > - */ > > - if (READ_ONCE(memcg->oom_kill_disable)) { > > - if (current->in_user_fault) { > > - css_get(&memcg->css); > > - current->memcg_in_oom = memcg; > > - current->memcg_oom_gfp_mask = mask; > > - current->memcg_oom_order = order; > > - } > > + if (!mem_cgroup_v1_oom_prepare(memcg, mask, order, &locked)) > > return false; > > - } > > - > > - mem_cgroup_mark_under_oom(memcg); > > - > > - locked = mem_cgroup_oom_trylock(memcg); > > This really confused me because this looks like the oom locking is > removed for v2 but this is not the case because > mem_cgroup_v1_oom_prepare is not really v1 only code - in other words > this is not going to be just return false for CONFIG_MEMCG_V1=n. > > It makes sense to move the userspace oom handling out to the v1 file. I > would keep mem_cgroup_mark_under_oom here. Hm, I don't see any usages of memcg->under_oom outside of v1-specific context. I probably miss something, can you, please, clarify? > I am not sure about the oom > locking thing because I think we can make it v1 only. For v2 I guess we > can go without this locking as the oom path is already locked and it > implements overkilling prevention (oom_evaluate_task) as it walks all > processes in the oom hierarchy. It's a good point and not obvious if we really need anything of this on v2. I guess no, but will think a bit more. Thank you!