Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5756574yba; Thu, 11 Apr 2019 05:17:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqwdlAkfvNq6/AG4WVoYU0sX/dd2Hp8sp5SnijhJm637NeAPJ8H2HWgKcDD6uMItrJfk7dWi X-Received: by 2002:a62:4602:: with SMTP id t2mr49252602pfa.26.1554985056549; Thu, 11 Apr 2019 05:17:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554985056; cv=none; d=google.com; s=arc-20160816; b=bIet3LyNZUur+c2pe3TCgnXd21o9RVLQkcJ/06ft6LyWl0y5a6cJNPWVu+XIkoF9Qq C0rFKS2DlIhbamrvsSsQ1H4BlbiMXAt3rHb6R0OCChpDdEqu77dMy/HqHMZbpXlxnbvk xVYgKYj5ZsE/UDMumQYPAUDh/ec9WxWp666/Q0weJ8MnbXXVCtKkhleMHvN+7gXqvF5c zD3z8QmznwKuuXIO6vECtktQbr5OPzCBsGjvBy4iXPDITxMbQvTJaGKHfF6FE4R1q5g7 UcenTb2C7FnvFhyog5ZhDhoW1L1zTI6MHFICeach8mdvgmunL7ABKAbTV/Qdhg15Z0eu cYiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=edXSCP5OqM8PLr1UPZsTym0h9sgEKE5VTgkryqhvo5g=; b=lEi5pYEDeowCtfEGfIjTwlKCCrVl0pOsp+9MwSwwrFHT2aofzP5WAvUUalX1K+O6Cx 2hxaZblxfIfSH6I0mJTed9Y8/7O5tmgRRwmMkOOem6F0/0vOWxU3UUlC+2u6D/XYjjRI mAW4JmmCwpBog6y9He3wYVGI4A9kMSvmzmbWhHCo3LuaAGJPdo5n5pBSNsfY6BMl5GFu RWNFBu62xDCQsXDefzhNcwgyLswqOhGGKaWJ7M6sQD/DrwpvYxYz6efJb5SPCwI1gOVp kIMhmkkHwxP5ccFs36/I6oy7PLOO5FXHX+v4y5TbM/e6rgWcihgrbOHQfJ8zCUaLcPo3 BMqA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si450095plb.279.2019.04.11.05.17.20; Thu, 11 Apr 2019 05:17:36 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726564AbfDKMQj (ORCPT + 99 others); Thu, 11 Apr 2019 08:16:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:50314 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726073AbfDKMQj (ORCPT ); Thu, 11 Apr 2019 08:16:39 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 80279AC4C; Thu, 11 Apr 2019 12:16:37 +0000 (UTC) Date: Thu, 11 Apr 2019 14:16:33 +0200 From: Michal Hocko To: Rik van Riel Cc: Suren Baghdasaryan , akpm@linux-foundation.org, dancol@google.com, jannh@google.com, minchan@kernel.org, penguin-kernel@I-love.SAKURA.ne.jp, kernel-team@android.com, rientjes@google.com, linux-kernel@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org, hannes@cmpxchg.org, shakeelb@google.com, jrdr.linux@gmail.com, yuzhoujian@didichuxing.com, joel@joelfernandes.org, timmurray@google.com, lsf-pc@lists.linux-foundation.org, guro@fb.com, christian@brauner.io, ebiederm@xmission.com Subject: Re: [Lsf-pc] [RFC 0/2] opportunistic memory reclaim of a killed process Message-ID: <20190411121633.GV10383@dhcp22.suse.cz> References: <20190411014353.113252-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 11-04-19 07:51:21, Rik van Riel wrote: > On Wed, 2019-04-10 at 18:43 -0700, Suren Baghdasaryan via Lsf-pc wrote: > > The time to kill a process and free its memory can be critical when > > the > > killing was done to prevent memory shortages affecting system > > responsiveness. > > The OOM killer is fickle, and often takes a fairly > long time to trigger. Speeding up what happens after > that seems like the wrong thing to optimize. > > Have you considered using something like oomd to > proactively kill tasks when memory gets low, so > you do not have to wait for an OOM kill? AFAIU, this is the point here. They probably have a user space OOM killer implementation and want to achieve killing to be as swift as possible. -- Michal Hocko SUSE Labs