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 BBD06C2D0A3 for ; Mon, 9 Nov 2020 15:39:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 09A71206C0 for ; Mon, 9 Nov 2020 15:39:40 +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="bdMxPQw/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 09A71206C0 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 1B6776B0036; Mon, 9 Nov 2020 10:39:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 166DF6B005C; Mon, 9 Nov 2020 10:39:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F23636B005D; Mon, 9 Nov 2020 10:39:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0193.hostedemail.com [216.40.44.193]) by kanga.kvack.org (Postfix) with ESMTP id C65A86B0036 for ; Mon, 9 Nov 2020 10:39:39 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5ED0B1EE6 for ; Mon, 9 Nov 2020 15:39:39 +0000 (UTC) X-FDA: 77465289678.28.line14_4608461272ed Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id CCA646C13 for ; Mon, 9 Nov 2020 15:39:38 +0000 (UTC) X-HE-Tag: line14_4608461272ed X-Filterd-Recvd-Size: 5056 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Nov 2020 15:39:37 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id b12so4915003plr.4 for ; Mon, 09 Nov 2020 07:39:37 -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=VzY1hjUfAc6GKStaIwRVGn/GJgL4dhk/7nsRnJXrCMQ=; b=bdMxPQw/a1HFaqKUHUJOjpWmnGfObjuyHg3vqLsChRMyZCc0xd8WlMn0alLnGwwmoJ hFKAcPgMf62pzGTyUEoweIpqlv7RqSxvVGJEu/sTpVbn19yDYa+5N8YMoEIaFFENpaSY NDheeAJAswLF8QD0pBRjGRa0DtI5qlY81KF1g73vaMhaWDg7lXncwct3Gg1riqlN0h2Y ilpNad9b/BV1FOlSHSfMfiEsK6LzeywPdzbGiEWlU2rmERnDMqJNt7Ffv8vNX6I9eLdX YSIwvbEogKdb18WGHqhFR5uuLHBitZJu/jDftHgboQajmAKsWTMgBWMVNm+UP8oFaGsO qZCQ== 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=VzY1hjUfAc6GKStaIwRVGn/GJgL4dhk/7nsRnJXrCMQ=; b=JP7q8x0+gCL26oVz6rYYUysLsQuAUCUOY7Q2joFEsJr9y+v1K2TYI10wdXYRF30Y0X +4mU8JwnUGTtt9i4ImCYxTzug6WaOzv0z7CMIF9t6aK5ttTX/VOceM6r8ssw/fvz/81n QqVrrcWgfqj1MKZ1kwFx/t/6CT9+07Xc4Arcna/P7MyE7gy16mFVkn8bdcC2CQx3he7K OAUUbzgCXx+eEE3P1LQWpxaLIEMZVibHe0BbWP7uXxvdxEg2bkOshkFRK1fNJCr7hUH2 8SXyIB1EIpKtFm2emQ3YQE0oukNM+CGBZUXv7c2C+QanV97rjVlfYBAM4Z+bnCZ2Z/Q/ rioA== X-Gm-Message-State: AOAM5303A7OFtGThJlbF2YJN45TXDr1rVBRTjfwfKBVNxnBAfKMbnklX nzKxrW00QOzM1r5g3ab0ygQ= X-Google-Smtp-Source: ABdhPJwoHWyxKnfYVEVZ8gwkXHNZBtYvGhW9WbvhHURsi/7lCWGxELpqEmF0jppDFWS7+BtgyruOUw== X-Received: by 2002:a17:902:8f83:b029:d7:ec99:d2fd with SMTP id z3-20020a1709028f83b02900d7ec99d2fdmr1470629plo.17.1604936376507; Mon, 09 Nov 2020 07:39:36 -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 l190sm11270280pfl.205.2020.11.09.07.39.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Nov 2020 07:39:35 -0800 (PST) Date: Mon, 9 Nov 2020 07:39:33 -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: <20201109153933.GA449970@google.com> References: <20201106203238.1375577-1-minchan@kernel.org> <20201109073706.GA12240@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201109073706.GA12240@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 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. > > > 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. 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. Any suggestion?