Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2186814imc; Tue, 12 Mar 2019 08:40:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZ2D5m8NN062EuOogXnr2udWzAejQm0ROgvr/T287jOQdzp6XOcb+d5/ITGl+Y9GjostNN X-Received: by 2002:a62:2008:: with SMTP id g8mr38640076pfg.121.1552405215798; Tue, 12 Mar 2019 08:40:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552405215; cv=none; d=google.com; s=arc-20160816; b=HReMqcTBKdnNnILYx36o4DvfVFKjYHbFAMU4/zseHBcD5g+ltx2v32kWx5sj9JIjJP +k52gDSyDI3sR92lB0vCFHdw4LgEZAm9NyCMMmi46LWN2DMfsiFV3V6cpV+F9Xqk5NOH F1QiBhpq9oRrEbxj8z9v7n2OwhYgMgQrLxdI/q6jZ5NDr6wfM8R4G8k3ogcGvGIM1VVb pK+iUHkasLb6DBaqSOzBM/3w94WwWMtg4AXshjnJU34wqHw/j3Dn2t8TtwdBYcSZfflP w5OXdy7R2RMvtLyPUsNgL6BziuzLXHTS7Zjpxr/lbgMo88u87d8EbdpCPEV5oFZqL4qM ShHA== 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=bF0KTi4f7aIMB3DIQctyhxDicchsDJrp3U+n4tBeGMI=; b=tAv1hGsl6nW+qNPgbIJ5/V02wl2YuHOes6mvjCoFfmczmnOiZG1hNug6H6etJaM5H+ igr64nqSdl119bIRe0OOw+KECRrmR1k3UIVaZoj+K2S4OloR65S09oUKEALnxveppD2M p/woMMPhUq42oMsGTB9GCDqFoICqUtA1okQWYz39DdntRcNFky1AIHrNYm53iCo0duhW CWLja92SeoXJLlTSdljxez0LjHrMCPNsZfRhRhd1QwNONKp0eXDJGnyIMZoECF9gMLpb HeMGYptQ1Zhkp/pPbandh5nZZ52/ES0RmATIp7CP12M2QYBq4wLVodT1vbmvocJpDKbd mJKw== 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 e39si8804306plg.23.2019.03.12.08.39.58; Tue, 12 Mar 2019 08:40:15 -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 S1726510AbfCLPja (ORCPT + 99 others); Tue, 12 Mar 2019 11:39:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:44990 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726174AbfCLPja (ORCPT ); Tue, 12 Mar 2019 11:39:30 -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 E7525B172; Tue, 12 Mar 2019 15:39:28 +0000 (UTC) Date: Tue, 12 Mar 2019 16:39:28 +0100 From: Michal Hocko To: Matthew Wilcox Cc: Suren Baghdasaryan , Sultan Alsawaf , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Ingo Molnar , Peter Zijlstra , LKML , devel@driverdev.osuosl.org, linux-mm , Tim Murray Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android Message-ID: <20190312153928.GW5721@dhcp22.suse.cz> References: <20190310203403.27915-1-sultan@kerneltoast.com> <20190311174320.GC5721@dhcp22.suse.cz> <20190311175800.GA5522@sultan-box.localdomain> <20190311204626.GA3119@sultan-box.localdomain> <20190312080532.GE5721@dhcp22.suse.cz> <20190312152541.GI19508@bombadil.infradead.org> <20190312153315.GV5721@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190312153315.GV5721@dhcp22.suse.cz> 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 Tue 12-03-19 16:33:15, Michal Hocko wrote: > On Tue 12-03-19 08:25:41, Matthew Wilcox wrote: > > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > > > Yeah, killing speed is a well-known problem which we are considering > > > > in LMKD. For example the recent LMKD change to assign process being > > > > killed to a cpuset cgroup containing big cores cuts the kill time > > > > considerably. This is not ideal and we are thinking about better ways > > > > to expedite the cleanup process. > > > > > > If you design is relies on the speed of killing then it is fundamentally > > > flawed AFAICT. You cannot assume anything about how quickly a task dies. > > > It might be blocked in an uninterruptible sleep or performin an > > > operation which takes some time. Sure, oom_reaper might help here but > > > still. > > > > Many UNINTERRUPTIBLE sleeps can be converted to KILLABLE sleeps. It just > > needs someone to do the work. > > They can and should as much as possible. No question about that. But not > all of them can and that is why nobody should be relying on that. That > is the whole point of having the oom_reaper and async oom victim tear > down. Let me clarify a bit. LMK obviously doesn't need any guarantee like the core oom killer because it is more of a pro-active measure than the last resort. I merely wanted to say that relying on a design which assumes anything about time victim needs to exit is flawed and it will fail under different workloads. On the other hand this might work good enough on very specific workloads to be usable. I am not questioning that. The point is that this is not generic enough to be accepted to the upstream kernel. -- Michal Hocko SUSE Labs