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 217B2C6FD1C for ; Tue, 14 Mar 2023 11:07:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65D8A6B0072; Tue, 14 Mar 2023 07:07:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60D638E0002; Tue, 14 Mar 2023 07:07:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D4E18E0001; Tue, 14 Mar 2023 07:07:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3E0086B0072 for ; Tue, 14 Mar 2023 07:07:37 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 01B03C0417 for ; Tue, 14 Mar 2023 11:07:36 +0000 (UTC) X-FDA: 80567228154.16.229931E Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf09.hostedemail.com (Postfix) with ESMTP id 11312140012 for ; Tue, 14 Mar 2023 11:07:33 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=shopee.com header.s=shopee.com header.b=FHcLDDbk; spf=pass (imf09.hostedemail.com: domain of haifeng.xu@shopee.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=haifeng.xu@shopee.com; dmarc=pass (policy=reject) header.from=shopee.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678792054; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tj5M1DBlPFQKNPA8pa3BKKPfvgZNjQEcGkRad3D+XbU=; b=kgAf5uRS/4FyL6/zsjMnxG2k+jD+h706r8+cyJ/G1oK1x7SZnJSSiAmp3ghDKn3Pnq6r7Q WZXCXx0UAEjZkFHBsBagQzeYcrhfPevmZJcKSB3S69fTXRrvfBVze0yxE6NelAwuUB3qLl ND4Jy13QMPcxt+GI4S31/wnJp1Wa5I8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=shopee.com header.s=shopee.com header.b=FHcLDDbk; spf=pass (imf09.hostedemail.com: domain of haifeng.xu@shopee.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=haifeng.xu@shopee.com; dmarc=pass (policy=reject) header.from=shopee.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678792054; a=rsa-sha256; cv=none; b=aeuQSKkE6B/pp+pkE7aZ+1dQmijuQ/A8JDSjt1kpq/wMwjWq23ldFeQLHFwxN+TcREzaDJ A5FMyTcXMF+wJ5L83cVUl/moeQ9A1aUB2c1v8lc/zqzh1jP8K699iCemml4+4/ehvc3C46 F1CUg8ThjTI2di6vEfGOVat4J0YllR4= Received: by mail-pj1-f54.google.com with SMTP id j3-20020a17090adc8300b0023d09aea4a6so5642641pjv.5 for ; Tue, 14 Mar 2023 04:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shopee.com; s=shopee.com; t=1678792053; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=tj5M1DBlPFQKNPA8pa3BKKPfvgZNjQEcGkRad3D+XbU=; b=FHcLDDbkk9I35ygxiufT+m09fqRJ1UdOPx+YDsUFdkKb4xhVYFxiK2Zb5th7+JqQZX RDBc9hJBYDYoLITSzF/Cn3DxypZGjtaKmhUoiimqSXO0NCpepHFJeK4mLoEMPnqIyq6Y bB0SwOehMwEurTQ7k/b8MhI3GFzz2I7DSpplF+qa0tXxxHJYcRTMpejpHLG9rHk3mfGn EDiqTIl4cqQvf+6eiVHYCvr/hgoJAtSFShuUgjk48mGUSACszNiPt01m2R1VUcTLh+ur kOMRtuCx9+UNPfF+rQtj2zq4DEPQPT0iZKw3BBQaujhnSUfWYT9u8pgFlOLADP0bxyBp GO4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678792053; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=tj5M1DBlPFQKNPA8pa3BKKPfvgZNjQEcGkRad3D+XbU=; b=vIazA4oPg7D/oYp9QOLI3xZV526J3oTC4G3bCELlNlHkTpaLxWTz5pTaS5FSOHC9Ep uS8v2dkLjJY+CpoqXH4V4bvgjDUh/vxYhi+5PRgRf6rHwDZKinqKp8xCHFwps2eJovYv mVQPqrcdJrgbl1N9nBvClWYwaMJo/PnID52ckyCDH1aQ3Y9Gp6vFKNSFn/c3/xPAdB6m VT/f1Yq0aHmxla4W/dkXlBIonc1hOwvlC3i7kZ33iVn/C2ht4MZDefYLmEXPJuqdTYRI 6Qr93INuYqTJcU9w7O3FUgh9cs5vSBJlG3Db/7LJxrVuKdk7R+ErKLUnXpLCUW14Kd+v UOgw== X-Gm-Message-State: AO0yUKUpYF/9MoVKc9MAGp3GKVndn0g6kpIFsXYlb15npyY6+xmLiUne OoJ3hSU+zmhqXl327WqauHzjNQ== X-Google-Smtp-Source: AK7set+jwD1nbF5/u/u36amtxCpZSNYc594uix3nPJP5+kNWShsxUOpAfZ7kkXfkNo1NCTEkRzkcXg== X-Received: by 2002:a17:902:8c94:b0:1a0:4be0:94a9 with SMTP id t20-20020a1709028c9400b001a04be094a9mr5169648plo.48.1678792052847; Tue, 14 Mar 2023 04:07:32 -0700 (PDT) Received: from [10.54.24.141] ([143.92.118.3]) by smtp.gmail.com with ESMTPSA id ku7-20020a170903288700b00189ac5a2340sm1514893plb.124.2023.03.14.04.07.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Mar 2023 04:07:32 -0700 (PDT) Message-ID: <3654a73e-6817-4247-73b8-4604efe4a309@shopee.com> Date: Tue, 14 Mar 2023 19:07:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH RESEND] mm/oom_kill: don't kill exiting tasks in oom_kill_memcg_member To: Michal Hocko Cc: shakeelb@google.com, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230314091136.264878-1-haifeng.xu@shopee.com> From: Haifeng Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: kjpm6hgpg9rabwtxz49o99o4qz4r9zut X-Rspam-User: X-Rspamd-Queue-Id: 11312140012 X-Rspamd-Server: rspam06 X-HE-Tag: 1678792053-897115 X-HE-Meta: U2FsdGVkX1/GIXMdqgIBTdqJ/VxRFtkqSn8vGu57SfEMoYyBuX9xu/AfMTkFBOcmA1QXThCEcKdTIrAn+A33st3Z/7p9C7Csqz4zD2JAapFHvmlzOCiL/CkURQL/WyGr2QIqkeypZO42ae5AuVFMm3r84eCn736CTBk3rUTbQXvUFzn7vCu36gGHbVomBYEVZ7+i242V5Jk6rp3b45DFYjy9KxMdC7Lfgk2I1OcT7f3tp3CbgqEdULk2bAVqpXGORWFGASSxa/7Ns0XyedROad2t3ofNRI1vTnxkeW13D3urb3k376RunCJ4FlIaF6IqHHD0odgx7up+CpHj1gN1P1Uh9S29haZkUTdNCLjPlO7BEKPTQz62y0o0jT/jlM88qfbVaDAIn8uzSu6nYeHhPTOvMT/IP6t1ihyDyZlvBkV05EJ9EpCKEs4Tqps0HYelfB1aTKBRz5qujYucbYKNUjaGjCNcYtYCLl8ZMlSzH6OUl1NOR2B/SmPOcl4dSEXrJAcAYd+fch/rn32tXLnrdcjUK9VS61//oNWGL7csHDcfofjv9HMio7NEn7xRbruiSH8WiQdtRPjVttodD9Y/RUOAVfe9CV48yIXROT/Zktoeu2d1MKnC+Yu2vuiLMBTszJNSk3MDbvie/2auSCN1VatCfZPVM3M6wEapnprQNDtb1/gOVSWstR76/2fo9GaFwNqeKXlMo8CkLoB1/aziu7YsKbvAqGTifWiQnTJ8o0vMiEoOSmbJqCQCmCRuQ5PVq1yILl7KbkCNlPhY0UD04221zPqfaKB3Hn1VZbfr6lUtf4STCJXeQPyJRWxw1Saf6n9DDBwTWdX8vgAUFMG/mKKtFnYRFM0H0XHHu+FPsjU55VtRTLTOPexhqBNZBaBmtsr+YKvUoGQyFdwHQpeglY8ZyziTHWkLdhPlPrWz/261Mv/7cvovBIk01I2vYBvkTlg21VVtI/YQU5yM0sz YvTl7O5V Ktx8XT1pfCMCTxCJIpCvEadp3vYOgkD2uVrSmPMmW3jzu+kxRu7wcKKPGuzz5EiRYjbpDuqycL4HqkuiR3W9g/B+CdirhihKSpOD3S5CcIYc9zHby8EgZI4WCuuM2GzTlEo5WsxSIc7r/8If/4ax/Gew5KCYfbyCKFsAMQX8h2DC3PxIpokquqn3OaQ0TrR/xb4R4wbrJE5L3VeQcf72DIy34jSIonShQZqfb8K3h1vDRGyObe2aEuOC3sa+GII5TfGoPX8spWsx1mVJMWClNOuhf5in28VCtwrTXsW6XlXUVOELtVMQ2nOu0jLdKZpWJreLsdrsk/AKxiXM+/uiSJLjSk38WP5mijuUsjCCz8OqbS2NQCZ3I/f6LWuxjyZCWRBpag4ot3C11PSldP3d4KMj/nYJBrKZZVVJ/ 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 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. >> 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.