Received: by 10.213.65.68 with SMTP id h4csp3844042imn; Tue, 10 Apr 2018 05:39:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+RbwC+/WzaumZpBiH7rVK899BJdyX7FAWzPWVj5WQYY0rdG2vOhfWcTvqqoJXIhI6m2K0M X-Received: by 10.99.172.86 with SMTP id z22mr177101pgn.35.1523363987655; Tue, 10 Apr 2018 05:39:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523363987; cv=none; d=google.com; s=arc-20160816; b=kM5jSNmQlF4mPuFyV7GRQvEJKDQrcs69326MgxYiEn+ywlE3kda/RlBlp3RCC5dSTJ uGlcwYOICqjiCW1qyPB9XM19BfSD1cUD3I7uIlmKdgFtoJStRHaliHI9sG+2GVgEpYkr TleLfEZL358pLh1Bito0CpPGjE9d8MOgpuPnBuHq9sbxluB37dIMCEZnw8Kfbm0NUp3t 5ENmhiPy2J/lm6Ay7MUaYtD9SvCLUY0K5y1epZGMuHpolLoX9GmuBwCdhNERaT0hCpgZ Ss98jVRPkezHfoKSIM7yFVaKuXmgtnCg5njdfByKg2CNUENF35uy733Cul5rgxD0hwNH gz+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=/Y5EfGoEoXHxr5oxj1pMF3/3s3ludL9G0IF0hsofcMU=; b=xphmglju8fvHQU5b/X0l4eFwwa35z6UqZdDkF0njgSg/VjhUzkbnYBJeP5VurJ1Ubw m6+AiFG9WeL3MC8ou4LTsnwvPaROk3/JzmGX67EI4YmeitXLqt8DdCFpfRB4pWfMDZMC MMDf67w0Kai/QAaR9KfBfS8BvDVgAQUICOPdtbdyW4m9Bh28yEGhgVjVodpbEqFNZzbO gAzBBb0GD7fq3Q3bgKRG+fGZd73+LZ2vlahPghxNP0rcs+Q9ALcsNknwXGl+ncJ714Zr Ak2y80quDShZVL4vLgksil24HAWiOJFdt56IZcRa3/eYm6bWna7byWBrPC8+d+9hKfPS 1auQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1-v6si2674121plk.611.2018.04.10.05.39.10; Tue, 10 Apr 2018 05:39:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753421AbeDJMga (ORCPT + 99 others); Tue, 10 Apr 2018 08:36:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:36606 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753394AbeDJMg2 (ORCPT ); Tue, 10 Apr 2018 08:36:28 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7458821771; Tue, 10 Apr 2018 12:36:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7458821771 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 10 Apr 2018 08:36:25 -0400 From: Steven Rostedt To: Michal Hocko Cc: Zhaoyang Huang , Ingo Molnar , LKML , Joel Fernandes Subject: Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN Message-ID: <20180410083625.2c904ab2@gandalf.local.home> In-Reply-To: <20180410122706.GH21835@dhcp22.suse.cz> References: <20180410061447.GQ21835@dhcp22.suse.cz> <20180410074921.GU21835@dhcp22.suse.cz> <20180410081231.GV21835@dhcp22.suse.cz> <20180410090128.GY21835@dhcp22.suse.cz> <20180410104902.GC21835@dhcp22.suse.cz> <20180410082316.263d34ec@gandalf.local.home> <20180410122706.GH21835@dhcp22.suse.cz> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Apr 2018 14:27:06 +0200 Michal Hocko wrote: > I would rather that the code outside of MM not touch implementation > details like OOM_SCORE_ADJ_MIN. It is really hard to get rid of abusers > whenever you try to change something in MM then. Especially when the > usecase is quite dubious. Fair enough. I was reluctant to use the OOM_SCORE_ADJ_MIN in this case. Perhaps I can create an option that lets users decide how they want to allocate. For people like Joel, it will try hard (by default) and set oom_origin, but the user could also set an option "no_mem_reclaim", where it will not set oom_origin, but will also use NORETRY as well, where it wont trigger OOM and will not be the designated victim of OOM. But it will likely not allocate memory if the system is under heavy use. Then for Zhaoyang's tests, all he has to do is to set that option (or clear it, if the option is "mem_reclaim", which is what I'll probably call it). -- Steve