From patchwork Mon May 28 12:43:13 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10433529 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 944A6602CC for ; Mon, 28 May 2018 15:54:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 836F928AE7 for ; Mon, 28 May 2018 15:54:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 767F028AF7; Mon, 28 May 2018 15:54:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=2.0 tests=BAYES_00, DATE_IN_PAST_03_06, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A6ABC28AE7 for ; Mon, 28 May 2018 15:54:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D6DD6B0269; Mon, 28 May 2018 11:54:00 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 65EE26B026C; Mon, 28 May 2018 11:54:00 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D9816B026B; Mon, 28 May 2018 11:54:00 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl0-f70.google.com (mail-pl0-f70.google.com [209.85.160.70]) by kanga.kvack.org (Postfix) with ESMTP id 084F96B0269 for ; Mon, 28 May 2018 11:54:00 -0400 (EDT) Received: by mail-pl0-f70.google.com with SMTP id b31-v6so7808572plb.5 for ; Mon, 28 May 2018 08:54:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:subject:message-id:references:mime-version:content-disposition :in-reply-to:user-agent; bh=/kSgh5rcL63qY5fhWZ1Qu6hybNYVzfEcaF8JCQCYPPE=; b=cjBI6dm2+rzBm+5HKL75YtcVCX9f9LS1yXkyBJnyat7atjKu6jeqstQBjHlOEOUg4B l3Xdvg/iPSC98uvj9T2/qBKpJ9Y2ylpuOJ0woFV5M5uh4iqJ3UXgKYYEOiqhUtW+u6Vq QhsD6hy0Nt0RW6UC1PJhyC8e3FcVMG1t1Q5fxPUN+bAqvXD3ojNDlgjGz7xxeIkQ52vf Pdgc5JeuqfOzKdn6UwTdNdZxHc7VHK0PIAwdHH4myCJUf9GAAvsqMQenAHFuNf1BdPyS PHMx+1aT1rYgUHEL6DUiyfbQcCCi7mgtzo4TJzAYgwnoKwSPYLv/oNGCS7vHIUE8BwGA JRqQ== X-Original-Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Gm-Message-State: ALKqPwcWEkmkAzxVRuVlDWT1xaMX2UFhu2sQ8W2LBGCAPF4/yolxCwbh UNZAzKtTKs7QIU0UhDFwxpvpbeXZzWbQGTijoYGj9s28exLuUWnowvQ0zDDUhDQ5daYzDP25M/F 0o9qC8KIxmcojrKbMdhOL67kmuqt9Cur6Q8GKGJsUN7jd7+pPMrpPWbWQ0obXS84= X-Received: by 2002:a17:902:6bc7:: with SMTP id m7-v6mr13840625plt.162.1527522839725; Mon, 28 May 2018 08:53:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZplHrlCADnnGDHcue3iqpMRqirBjMlQDUlVUX4/rYNn9E6U7la/JJehu8qFz9WSvRoP86RN X-Received: by 2002:a17:902:6bc7:: with SMTP id m7-v6mr13840597plt.162.1527522839022; Mon, 28 May 2018 08:53:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527522838; cv=none; d=google.com; s=arc-20160816; b=z07pqKmMx7B0J4zJXdtP4/mZTjK5UzccoV1zKzIOJwAcfmb8lZB6lvUot/AEUlFa1z ohTCfR6qOD8YWJBorHQRiCtuIbBPPqpi4AYWzq54gUrYaJJoNRRREuYuxeCPreq34wOg qJ0JyOkb2TB6Z2lTfOjh4NfBU3cBk/Aea1U8ApxkWusWKXiDYgcMBMXJzwuI3z67W7Ht bWRqwasazcaV93ixsztOzF3N+8RTS1hj5INW87CXW1mQBybOheGBxTIGPU4iDFBUgoZ7 pXs+RgGI3N28UW3QMFgPp0lNGYq8yrS+P/EUfbxjH26UJt6/mROcGYBkLn4YlPb/kDr4 KO+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=/kSgh5rcL63qY5fhWZ1Qu6hybNYVzfEcaF8JCQCYPPE=; b=hu3iWjIb3Jc2r3IneSWWW/18rToWHNbcBFEIpQAD1Z9eqg0m6Gswfm+kO72+bAS42r +dX2AcmyRy34wnQGV3SUgqtzE5Cd2R/y7xJgJg+m/hu0b5tZe3vlhdicUSaWQhopNjDb VhK8PvuTZ7qDrpdA3fLF51iRUd5Dkd4v94/TULjbXoWO2mM1mXzyQSdUot/1kjNODayx gHn9XHBNdSx1OeiOg9ljYQd1qXySrTEV6dcjpYHz0szOwCyojevpWkHTBfWHSfR2seEn c0ASXpqGu/SdogwnNgSAQUt4NA3hcpKI6pjqe5kmGdnYSNO3psm7Bmlbd71iv8SyAGPd GS5w== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id b70-v6si30780109pfe.265.2018.05.28.08.53.58 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 28 May 2018 08:53:58 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) client-ip=195.135.220.15; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8946FAE35; Mon, 28 May 2018 15:53:55 +0000 (UTC) Date: Mon, 28 May 2018 14:43:13 +0200 From: Michal Hocko To: Tetsuo Handa Cc: guro@fb.com, rientjes@google.com, hannes@cmpxchg.org, vdavydov.dev@gmail.com, tj@kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, torvalds@linux-foundation.org Subject: Re: [PATCH] mm,oom: Don't call schedule_timeout_killable() with oom_lock held. Message-ID: <20180528124313.GC27180@dhcp22.suse.cz> References: <20180524115017.GE20441@dhcp22.suse.cz> <201805250117.w4P1HgdG039943@www262.sakura.ne.jp> <20180525083118.GI11881@dhcp22.suse.cz> <201805251957.EJJ09809.LFJHFFVOOSQOtM@I-love.SAKURA.ne.jp> <20180525114213.GJ11881@dhcp22.suse.cz> <201805252046.JFF30222.JHSFOFQFMtVOLO@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201805252046.JFF30222.JHSFOFQFMtVOLO@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.9.5 (2018-04-13) 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: X-Virus-Scanned: ClamAV using ClamSMTP On Fri 25-05-18 20:46:21, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Fri 25-05-18 19:57:32, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > What is wrong with the folliwing? should_reclaim_retry should be a > > > > natural reschedule point. PF_WQ_WORKER is a special case which needs a > > > > stronger rescheduling policy. Doing that unconditionally seems more > > > > straightforward than depending on a zone being a good candidate for a > > > > further reclaim. > > > > > > Where is schedule_timeout_uninterruptible(1) for !PF_KTHREAD threads? > > > > Re-read what I've said. > > Please show me as a complete patch. Then, I will test your patch. So how about we start as simple as the following? If we _really_ need to touch should_reclaim_retry then it should be done in a separate patch with some numbers/tracing data backing that story. --- From fa3b165c34937bf628f2eee7e6f0483c611167d0 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Mon, 28 May 2018 14:30:37 +0200 Subject: [PATCH] mm, oom: remove sleep from under oom_lock Tetsuo has pointed out that since 27ae357fa82b ("mm, oom: fix concurrent munlock and oom reaper unmap, v3") we have a strong synchronization between the oom_killer and victim's exiting because both have to take the oom_lock. Therefore the original heuristic to sleep for a short time in out_of_memory doesn't serve the original purpose. Moreover Tetsuo has noticed that the short sleep can be more harmful than actually useful. Hammering the system with many processes can lead to a starvation when the task holding the oom_lock can block for a long time (minutes) and block any further progress because the oom_reaper depends on the oom_lock as well. Drop the short sleep from out_of_memory when we hold the lock. Keep the sleep when the trylock fails to throttle the concurrent OOM paths a bit. This should be solved in a more reasonable way (e.g. sleep proportional to the time spent in the active reclaiming etc.) but this is much more complex thing to achieve. This is a quick fixup to remove a stale code. Reported-by: Tetsuo Handa Signed-off-by: Michal Hocko --- mm/oom_kill.c | 17 ++--------------- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 565e7da55318..7f12e346e477 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -1099,7 +1099,6 @@ bool out_of_memory(struct oom_control *oc) { unsigned long freed = 0; enum oom_constraint constraint = CONSTRAINT_NONE; - bool delay = false; /* if set, delay next allocation attempt */ if (oom_killer_disabled) return false; @@ -1149,10 +1148,8 @@ bool out_of_memory(struct oom_control *oc) return true; } - if (mem_cgroup_select_oom_victim(oc) && oom_kill_memcg_victim(oc)) { - delay = true; + if (mem_cgroup_select_oom_victim(oc) && oom_kill_memcg_victim(oc)) goto out; - } select_bad_process(oc); /* Found nothing?!?! Either we hang forever, or we panic. */ @@ -1160,20 +1157,10 @@ bool out_of_memory(struct oom_control *oc) dump_header(oc, NULL); panic("Out of memory and no killable processes...\n"); } - if (oc->chosen_task && oc->chosen_task != INFLIGHT_VICTIM) { + if (oc->chosen_task && oc->chosen_task != INFLIGHT_VICTIM) oom_kill_process(oc, !is_memcg_oom(oc) ? "Out of memory" : "Memory cgroup out of memory"); - delay = true; - } - out: - /* - * Give the killed process a good chance to exit before trying - * to allocate memory again. - */ - if (delay) - schedule_timeout_killable(1); - return !!oc->chosen_task; }