Received: by 10.192.165.148 with SMTP id m20csp537312imm; Wed, 25 Apr 2018 03:54:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo7JrJbsouOlI4iYLPYZfwrolAy/RHrADwibsiszrsNFQImVSsyIvgfsPwPyNmmvB65+ddu X-Received: by 10.99.115.9 with SMTP id o9mr3830066pgc.332.1524653672223; Wed, 25 Apr 2018 03:54:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524653672; cv=none; d=google.com; s=arc-20160816; b=pMse794xt7YdURhgFJtAHsv5Pdof0K7HWlJeLwTGJnds88UdgTatJ4Hk+FKf6/JI1X mOJoCp3TXiZ7QMVVsQ6kIpjuLjiHSvNNbm0IeGHn92GuIL19SKAUaEtlP/NgYtruWeEm PGC3JpfltRSP1QcO0N0mebsnBY9lD8t10+mFqZJbeX8zw2Z3KUBEwHVlECtAi6U2ABmj dDysAXTlGwu9T9+AuJUhKuppaUsJ8Qwnnk3Q2c9/lVN3O9DDMcrpAyi38gvbLmU4esm3 1SlRYSVgV7HLGKnLGt6WcwpY14ctGIJ5bcO0MwyKVCdOMryOw3IYX8nGwTl0MLMeQ3LK 7RmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=kEVyLK87zAjO1axPFoMtlc+94eOEkQArXxasK63tgsA=; b=ukoEgEO9YpNri2N+rrfl2abr9TEK6TfqB7zG3oBIKh85YLDjz7zkII+PyznRjx1GKV O5BaWLslpAb25azrQpY0KJg2grTKXW9ZAPL2JptqvIvDyKNEvH0cnU+UmmO61cryYKXJ idVc4YIntEQVSX1hZ/rrJsBFo1m2Vi4Ytqv4yUh976pZRs+JLyisIrPCQwUqdfpiq9Ph nbZX+mbi/v8YYgL7qexgVL3GW1aHeunX97OkTMeBfxLXvt0E/Lxq6TZSgqyiVvyBtfwZ XRTE1hko/jxGE/k/9xELtYRU4djo5ocykPmvZC+Tt8oPa6cZpA4tvEovJhIfxZ2R/DNZ 9oeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mLxMsexB; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p12-v6si17050698plr.131.2018.04.25.03.54.17; Wed, 25 Apr 2018 03:54:32 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mLxMsexB; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754114AbeDYKxT (ORCPT + 99 others); Wed, 25 Apr 2018 06:53:19 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:34485 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752630AbeDYKw7 (ORCPT ); Wed, 25 Apr 2018 06:52:59 -0400 Received: by mail-lf0-f66.google.com with SMTP id m13-v6so10583763lfc.1; Wed, 25 Apr 2018 03:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=kEVyLK87zAjO1axPFoMtlc+94eOEkQArXxasK63tgsA=; b=mLxMsexBabxDrqZv4Jyv+rsMYwYIntvQXvU7A97gi6+b6iEdtJy53+kHFu4v+2cC12 3yTVdjroGDr/wIb2uXZVnNqeovwlXvc3Wc99R58u/gKkzhEYomnmIxFynKQGNrVF75LK L9Wh53e5P/SH0UE7gTsYEwbaHeuv07duIsxvijzn5abU4Eaaivvpc1ea2GqWgCPY30jE Ew5LC7h9D8yLhPKaAEMIo4ah5/q5McG6CpTlREUycoAKXca+u4mY5isodW6dH2xItB3r l8MskAfBUSglVp+hrJcGjaGyoOBzZOftWmiW1wh+EfovnUTiWntA+bArGVsngFcbaVU7 j0QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kEVyLK87zAjO1axPFoMtlc+94eOEkQArXxasK63tgsA=; b=c3XhVLBZAL49UAyMIJs8fzQriSI95+q8UffYlnpwWN/1dVTJ52kQUH4UPFyo0ejh/d c/H4orvSlMZyumd7p/sBLud6Y8nFycGyJdAZ7s7U6Qrv0ZIDLMY3hDOCidfizEJQosqp OyZ1Q4oyf88lGXY2vysHIa/hqGhm+JRbbywndsqf3SFhOi9cnbwolG9T94nl10SsXcyp tWGnDN/Bueuc3opkdxQ4xVBDNjSo4cfn1rRthwPFq4Y5yQTiJCFkfdYu+D8PUxOB0AW4 A0Q5Kn37du9m82MWwmkpQ9vhczEg9GD1rlqe4hPUP8P4221RWyUS0rL2ZnklRiK2Yx4u L4VQ== X-Gm-Message-State: ALQs6tC/5AZbKwmui7UZ3mNp8yzAey2OYcwDaQ3llEtwQNzTZkGx/tSD 3hq3jMKtaPE4bhkprijKhGlYkA== X-Received: by 2002:a19:9f10:: with SMTP id i16-v6mr13611312lfe.29.1524653578374; Wed, 25 Apr 2018 03:52:58 -0700 (PDT) Received: from esperanza ([185.6.245.156]) by smtp.gmail.com with ESMTPSA id x76-v6sm3880774lfb.63.2018.04.25.03.52.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Apr 2018 03:52:57 -0700 (PDT) Date: Wed, 25 Apr 2018 13:52:55 +0300 From: Vladimir Davydov To: Roman Gushchin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kernel-team@fb.com, Johannes Weiner , Michal Hocko , Tejun Heo Subject: Re: [PATCH v2] mm: introduce memory.min Message-ID: <20180425105255.ixfuoanb6t4kr6l5@esperanza> References: <20180423123610.27988-1-guro@fb.com> <20180424123002.utwbm54mu46q6aqs@esperanza> <20180424135409.GA28080@castle.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180424135409.GA28080@castle.DHCP.thefacebook.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 24, 2018 at 02:54:15PM +0100, Roman Gushchin wrote: > > On Mon, Apr 23, 2018 at 01:36:10PM +0100, Roman Gushchin wrote: > > > + memory.min > > > + A read-write single value file which exists on non-root > > > + cgroups. The default is "0". > > > + > > > + Hard memory protection. If the memory usage of a cgroup > > > + is within its effective min boundary, the cgroup's memory > > > + won't be reclaimed under any conditions. If there is no > > > + unprotected reclaimable memory available, OOM killer > > > + is invoked. > > > > What will happen if all tasks attached to a cgroup are killed by OOM, > > but its memory usage is still within memory.min? Will memory.min be > > ignored then? > > Not really. > > I don't think it's a big problem as long as a user isn't doing > something weird (e.g. moving processes with significant > amount of charged memory to other cgroups). The user doesn't have to do anything weird for this to happen - just read a file. This will allocate and charge page cache pages that are not mapped to any process and hence cannot be freed by OOM killer. > > But what we can do here, is to ignore memory.min of empty cgroups > (patch below), it will resolve some edge cases like this. Makes sense to me. Thanks, Vladimir