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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 5AE1FC388F7 for ; Mon, 9 Nov 2020 16:27:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E29A220897 for ; Mon, 9 Nov 2020 16:27:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ngqxHvMO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E29A220897 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 715A96B0036; Mon, 9 Nov 2020 11:27:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 69D726B005C; Mon, 9 Nov 2020 11:27:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 564916B005D; Mon, 9 Nov 2020 11:27:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 1FCA96B0036 for ; Mon, 9 Nov 2020 11:27:27 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C174E1EF1 for ; Mon, 9 Nov 2020 16:27:26 +0000 (UTC) X-FDA: 77465410092.14.gold92_2717024272ed Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 909281822987A for ; Mon, 9 Nov 2020 16:27:26 +0000 (UTC) X-HE-Tag: gold92_2717024272ed X-Filterd-Recvd-Size: 6665 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Nov 2020 16:27:25 +0000 (UTC) Received: by mail-pl1-f169.google.com with SMTP id z1so4966107plo.12 for ; Mon, 09 Nov 2020 08:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3nZrjD1ndhIGrNkP0+j/bsTnARfkt2zQnVxA///gigE=; b=ngqxHvMOHZ9krz3j7E8GBdjjoeUp5kFsOrXgkfhPfUwJPXJQgvfDMOT/ovwjDJ6vS8 FwLF41B9BfiOl3PI2iq+EwzhsrcoNpCsVKE9dVQAUHySRdSK8lrF1kGwHbUdZgAnmu7f WrQRNQgRNdDV4EKr/33Aqpx8E5Wfr8UqtcyzuWD6DRo/o52DWjHD2mIJ+DtIemw4fzbP ouojNVMDR3YoD4Khp1a5oDFiIaknxuaXwo3R8TGlb7lXP6AscFAZ6l67c50M0r/K9l2u /U61S2shcAFWrX23YmZYHqKrbk7exiWjIMJ0fmf4jcolG6G9pHNV7RCQ0ZMJjbgqD1aN OkrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=3nZrjD1ndhIGrNkP0+j/bsTnARfkt2zQnVxA///gigE=; b=XQVTgHfAO23BEArkRSlJO0xGUTm4qb85VH2p9tu9NTMz2GAc+7Lh8AwOe7GdYLI0zR AfMzZPygmvXiZnSTVA0r4iJCx0V3p9vPdBnBDEtDQ8dUgpTwJxl7urKk7i5SoovsLvto p3aPaBQa0lfSOsV2E2EJTVCJTE90aUQOQdXrnZ2nWSae0DBgfA8ATq4hsLlIXKV6lT9X YNypURSC+uXdJgIGq97I3GwJz2Vs6yizu0dDgvlGJBYU/Fb86N0/9nDGK2fc4QlmGeRC c95dqD8GlD4u8Sgxc12GSaJhqwG2CCjWrqG1Fl1iHucstQojg749WQpuYKKORG+J9Slt +fSQ== X-Gm-Message-State: AOAM5331VR3zj+2/QqOCco+H2WTrcNkwaVl1OqmgBrjVkUJdkM/rC9KF YNwZseHKTYWQpPsRZ7/z41oErPJ4Ut0= X-Google-Smtp-Source: ABdhPJyH1Wkvkd9qt1aJTLqMlqUVOGs4B6DTonVdfTyFiTlLkFO8xwN0xfzear0FyS6X6HhDCwWK+g== X-Received: by 2002:a17:902:8508:b029:d5:af79:8b40 with SMTP id bj8-20020a1709028508b02900d5af798b40mr13116951plb.28.1604939245026; Mon, 09 Nov 2020 08:27:25 -0800 (PST) Received: from google.com (c-67-188-94-199.hsd1.ca.comcast.net. [67.188.94.199]) by smtp.gmail.com with ESMTPSA id w66sm12095969pfb.48.2020.11.09.08.27.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Nov 2020 08:27:23 -0800 (PST) Date: Mon, 9 Nov 2020 08:27:21 -0800 From: Minchan Kim To: Michal Hocko Cc: Andrew Morton , LKML , linux-mm Subject: Re: [PATCH] mm: introduce oom_kill_disable sysctl knob Message-ID: <20201109162721.GB449970@google.com> References: <20201106203238.1375577-1-minchan@kernel.org> <20201109073706.GA12240@dhcp22.suse.cz> <20201109153933.GA449970@google.com> <20201109160618.GI12240@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201109160618.GI12240@dhcp22.suse.cz> 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 Mon, Nov 09, 2020 at 05:06:18PM +0100, Michal Hocko wrote: > On Mon 09-11-20 07:39:33, Minchan Kim wrote: > > On Mon, Nov 09, 2020 at 08:37:06AM +0100, Michal Hocko wrote: > > > On Fri 06-11-20 12:32:38, Minchan Kim wrote: > > > > It's hard to have some tests to be supposed to work under heavy > > > > memory pressure(e.g., injecting some memory hogger) because > > > > out-of-memory killer easily kicks out one of processes so system > > > > is broken or system loses the memory pressure state since it has > > > > plenty of free memory soon so. > > > > > > I do not follow the reasoning here. So you want to test for a close to > > > no memory available situation and the oom killer stands in the way > > > because it puts a relief? > > > > Yub, technically, I'd like to have consistent memory pressure to cause > > direct reclaims on proesses on the system and swapping in/out. > > > > > > > > Even though we could mark existing process's oom_adj to -1000, > > > > it couldn't cover upcoming processes to be forked for the job. > > > > > > Why? > > > > Thing is the system has out-of-control processes created on demand. > > so only option to prevent OOM is echo -1000 > `pidof the process` > > since they are forked. However, I have no idea when they are forked > > so should race with OOM with /proc polling and OOM is frequently > > ahead of me. > > I am still confused. Why would you want all/most processes to be hidden > from the oom killer? If one of processes in the system is killed, the memory pressure disappear. > > > > > This knob is handy to keep system memory pressure. > > > > > > This sounds like a very dubious reason to introduce a knob to cripple > > > the system. > > > > > > I can see some reason to control the oom handling policy because the > > > effect of the oom killer is really disruptive but a global on/off switch > > > sounds like a too coarse interface. Really what kind of production > > > environment would ever go with oom killer disabled completely? > > > > I don't think shipping production system will use it. It would be > > just testing only option. > > Then it doesn't really belong to the kernel IMHO. > > > My intention uses such heavy memory load to see various system behaviors > > before the production launching because it usually happens in real workload > > once we shipped but hard to generate such a corner case without artificial > > memory pressure. > > But changing the oom behavior will result in a completely different > system behavior. So you would be testing something that doesn't really > happen in any production system. Since OOM is not instantly reacted, it still provides a good chance how the system reacts on such memory pressure until someeone releases the memory. For example, Android already gives lots of system processes to -1000 which could effectively disable the OOM at certain point. > > > Any suggestion? > > Not really because I still do not understand your objective. You can > generate memory pressure and tune it up for specific testing scenario. > Sure there will be a some interference from the background noise (kernel > subsystems reacting to external events, processes created etc.) but why > that is a problem? This is normal to any running system. Putting more pressure from background processes is okay for the goal but not okay for relieving th memory pressure since we lost the testing environment.