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 454BCC6FD1D for ; Tue, 14 Mar 2023 12:01:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC70B6B0072; Tue, 14 Mar 2023 08:00:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A77C68E0002; Tue, 14 Mar 2023 08:00:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 940838E0001; Tue, 14 Mar 2023 08:00:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 84D036B0072 for ; Tue, 14 Mar 2023 08:00:59 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1286D1C6529 for ; Tue, 14 Mar 2023 12:00:59 +0000 (UTC) X-FDA: 80567362638.10.3D6E33C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id C2E71160021 for ; Tue, 14 Mar 2023 12:00:54 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=iTAKSecp; spf=pass (imf08.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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678795255; 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=lTQFuSx5OvwviLwoEcnLxQ9UCA6ETsWKTme8RoUcpnc=; b=y4ytzJiVMzeHmurRjdmREKJGyd1fLsIyD40A2fQpZEXTsrpUyU9kaE7vA5W1eGf1SXsC1b 9D4JQOlIvqWVo5lYnqiYqZ/mMKxEqstxZB13sZN+GdFHL40KJV+ti+8e3aDAN7BgoQOroG 2sM0AePl6Qtjiqb0OOhHUNTF7Xu128U= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=iTAKSecp; spf=pass (imf08.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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678795255; a=rsa-sha256; cv=none; b=B10wVee/Vzf3WL/EsrN6sBq9KdcQNxT0h47nU9ogV9vidOuq03JacPvOSO6U0PHqo37hek x1PG3UfVldCnQI4nuOIDbaJC+bwB1ONIQew0WSbQMZybjt+ebhUe1I7+Czf7Yj+TQWevKc UOmDP/BZkJmg7HS+ua1MWyQoR5wNhsw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0C8FF1F88C; Tue, 14 Mar 2023 12:00:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1678795253; 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=lTQFuSx5OvwviLwoEcnLxQ9UCA6ETsWKTme8RoUcpnc=; b=iTAKSecpiygLm00M3Q7gwUbBdPE95L1gTdXa4WILHZbiGpA1qm8Bm9kybLdrftySSWv2dj Ur5ksIYqQ864+qgDeqc7NbR425p8RJyF44848kzq/031KP18mISEorl4FvmJ9a7M14gV48 3Cz0IiQfu33CGeQHRw+tHe1tNyecAdg= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F089E13A26; Tue, 14 Mar 2023 12:00:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id zgm+OfRhEGTHRgAAMHmgww (envelope-from ); Tue, 14 Mar 2023 12:00:52 +0000 Date: Tue, 14 Mar 2023 13:00:52 +0100 From: Michal Hocko To: Haifeng Xu Cc: shakeelb@google.com, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] mm/oom_kill: don't kill exiting tasks in oom_kill_memcg_member Message-ID: References: <20230314091136.264878-1-haifeng.xu@shopee.com> <3654a73e-6817-4247-73b8-4604efe4a309@shopee.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3654a73e-6817-4247-73b8-4604efe4a309@shopee.com> X-Rspamd-Queue-Id: C2E71160021 X-Stat-Signature: zhehna8mrmdm18hbq8ahygabmqjfdxt1 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1678795254-42959 X-HE-Meta: U2FsdGVkX188gvuCZpcEyYIO/LZgSiKMPoFQ0fTQ30UJ4F/YcQWNhL8RDqpPMeRfdXorqkBGG4OjHlOY4PS8YtE5USgyJf8Vi66oPzVsdyCb+Lr1sI30SfOY9QLcBtrGjhJbkYP1v1SLvcTLgKbCnUrdzMcshsqFT7gr7Ayn4mVGsTbXdTxgo0tNb9Edw2Eku1+VynlqIayo4JPAcYejYP1yUlwxi3DjwYdbP8nuxZQBu/W6h16UOLr8mYuOx3w2/PFfKu4Q+smSQWlAezUn74S8P301f7zfwZdLFIWTSdgKiwD5CaS9zK90sUDmlsz0+YLkNUYgye5IXqG1LeJE7xW1Dug9S3u7LRFD9XIUiI+RozExvzqN53eP+dJl+fB/zgedSv6IuxysDvNs2z2KuoTf9QpyR6Z2h5e1ILJYU79ryPF1fAVmh27J8kvE1af+NUerBrR0wlbqse9FFFmI7TxoOwVx9OFN+6FR5HLdVcC5rVct9DoTvTrfrC/+BhE4HXNp7x+50KTk9EfDuBDKu2qp0KV5fcWlQn7WaRDl46PhRU+XcXYfz364sYZghS31F/c496k/HYnVjdjuTTOFlVQWqPYDmLlBzqC354vIiahOUIZjpyXEimQZ90FZsI0bJmpr82fXm0zJ5nPx2tRgs6lpxAhnw3wuVeXcZhwOtDUKQWc4+KC8QxiLzQQfayUSZ5jca6przMF5SvvpqD3BMeDVj5o/46Dy8CCYi5oMrQsBU9LHGxx8BuLXRoVYvjY/MHgoCqpkY/vuw5ypu8xk9b+Jc1Ky+9yp8mUsOQ8yQpuu1t2kml48jQxSknm/NNVR+PR8M/Go9SsA5INawmR4423JpZ7kNNtwI8QnHxRlNSB3gJo40IDrS9XxtSjBFmXOuwExnQsF69swZ8xTX4+eWqWkB3rmWMqpOowwn5nTmEDTihw5HK/lCn6jDIVxBGw9DTibMup/9sPMDe03GI8 LDQfvWii oESn7VHHFYmtxWR+qJzZ9ucHYinyc6kdY6l8gVzBms6kYXj0mwmcgw5kXlQMz+MlyMqPg/s4VnPNZLVQ8PrRwYzfGVOeV5S/oMC1OMv0TF4U0vRURGXnm4Tjf7IwRhhK8+g1WyL0AHWYlrZd3sdzSDk3YHCj1O11fakEH4+BOkE5cCXKCaoCgDGmJ5AZSRTqxleEPTy9c96MyLQwkbUDonLuzYg== 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 Tue 14-03-23 19:07:27, Haifeng Xu wrote: > > > On 2023/3/14 18:16, Michal Hocko wrote: > > On Tue 14-03-23 18:07:42, Haifeng Xu wrote: > >> > >> > >> On 2023/3/14 17:19, Michal Hocko wrote: > >>> On Tue 14-03-23 09:11:36, Haifeng Xu wrote: > >>>> If oom_group is set, oom_kill_process() invokes oom_kill_memcg_member() > >>>> to kill all processes in the memcg. When scanning tasks in memcg, maybe > >>>> the provided task is marked as oom victim. Also, some tasks are likely > >>>> to release their address space. There is no need to kill the exiting tasks. > >>> > >>> This doesn't state any actual problem. Could you be more specific? Is > >>> this a bug fix, a behavior change or an optimization? > >> > >> > >> 1) oom_kill_process() has inovked __oom_kill_process() to kill the selected victim, but it will be scanned > >> in mem_cgroup_scan_tasks(). It's pointless to kill the victim twice. > > > > Why does that matter though? The purpose of task_will_free_mem in > > oom_kill_process is different. It would bail out from a potentially > > noisy OOM report when the selected oom victim is expected to terminate > > soon. __oom_kill_process called for the whole memcg doesn't aim at > > avoiding any oom victims. It merely sends a kill signal too all of them. > > > > except sending kill signals, __oom_kill_process() will do some other work, such as print messeages, traversal all > all user processes sharing mm which holds RCU section and so on. So if skip the victim, we don't need those work again > and it won't affect the original mechanism. All oom victims are still get killed. mm sharing among processes is a very rare thing but do not forget that task_will_free_mem needs to do the same thing for the same reason. > >> 2) for those exiting processes, reaping them directly is also a faster way to free memory compare with invoking > >> __oom_kill_process(). > > > > Is it? What if the terminating task is blocked on lock? Async oom > > reaping might release those resources in that case. > > Yes, the reaping process is asynchronous. I mean we don't need the work mentioned above any more. > "reaping them directly" here is that joining the task in oom reaper queue. I do not follow. In any case I still do not see any actual justification for the change other than "we can do it and it might turn out less expensive". This alone is not sufficient, just be explicit, because oom is hardly a fast path to optimize every single cpu cycle for. So unless you see an actual real life problem that would be behaving much better or even fixed then I am not convinced this is a worthwhile change to have. -- Michal Hocko SUSE Labs