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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE7B4C10DCE for ; Fri, 13 Mar 2020 23:15:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8ABAB2074C for ; Fri, 13 Mar 2020 23:15:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8ABAB2074C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E4D876B0003; Fri, 13 Mar 2020 19:15:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD6FB6B0006; Fri, 13 Mar 2020 19:15:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC6226B0007; Fri, 13 Mar 2020 19:15:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id AFFA16B0003 for ; Fri, 13 Mar 2020 19:15:47 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 78FDA824556B for ; Fri, 13 Mar 2020 23:15:47 +0000 (UTC) X-FDA: 76591898334.05.trip99_3269855519a0b X-HE-Tag: trip99_3269855519a0b X-Filterd-Recvd-Size: 3038 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Mar 2020 23:15:46 +0000 (UTC) Received: from fsav405.sakura.ne.jp (fsav405.sakura.ne.jp [133.242.250.104]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 02DNFZl8040143; Sat, 14 Mar 2020 08:15:35 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav405.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav405.sakura.ne.jp); Sat, 14 Mar 2020 08:15:35 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav405.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 02DNFZr8040140 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Mar 2020 08:15:35 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems To: David Rientjes Cc: Andrew Morton , Vlastimil Babka , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <202003120012.02C0CEUB043533@www262.sakura.ne.jp> <202003130015.02D0F9uT079462@www262.sakura.ne.jp> From: Tetsuo Handa Message-ID: Date: Sat, 14 Mar 2020 08:15:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 2020/03/14 7:01, David Rientjes wrote: > The entire issue is that the victim never gets a chance to run because the > allocator doesn't give it a chance to run on an UP system. Your patch is > broken because if the victim is current, you've lost your golden > opportunity to actually exit and ceded control to the allocator that will > now starve the victim. > I still cannot understand. There is no need to give CPU time to OOM victims. We just need to give CPU time to the OOM reaper kernel thread till the OOM reaper kernel thread sets MMF_OOM_SKIP to OOM victims. If current thread is an OOM victim, schedule_timeout_killable(1) will give other threads (including the OOM reaper kernel thread) CPU time to run. That is similar with your cond_resched() patch (except that cond_resched() might fail to give other threads CPU time to run if current thread has realtime priority), isn't it? So, please explain the mechanism why cond_resched() works but schedule_timeout_killable(1) cannot work.