Received: by 10.192.165.148 with SMTP id m20csp690098imm; Fri, 20 Apr 2018 13:47:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/WkrrLcAIUMh8EH2plK764UDRJCMD7V1Xu9eGzAJ0dmaCLKdT3hYRtBEkCXs1K9lilZroD X-Received: by 10.98.131.69 with SMTP id h66mr984535pfe.0.1524257267451; Fri, 20 Apr 2018 13:47:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524257267; cv=none; d=google.com; s=arc-20160816; b=i3q4LeLH/k0oPpgh6WY5nSBDNYWKMpCskneOeYtOEaVJQOyt+UFjfMmczQlwkipGR9 FDHZ6jBxhFjfXnwwMZNCe5raHEXcU6cVXuYF1YpXDyMgiXwjM3JCht7Ifee2v6CObQT6 0ZeWzxvAC6joC1fVI85t+kqXAlZqi8EmCyk4ht3UE5FsnooaKVNb45r9maM2ZcvngqWb 24P0z69FjWwT3KDC1ozpQgBxvsen/wQy585vTHWQocjuBO0ym8PhyNly+HihFv1MaXW5 19H86NCXfO/6Ko1sdtWO+EAgNXzROhwWtJK8tajdjIVG3+u1XN6CwVJ5R0kB/JKsKhE0 TYzg== 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:dkim-signature:arc-authentication-results; bh=gqeCfhZ+I/DmjHt7xg7+NveAtkYIXyAoOku859mXGtM=; b=olUOMiTHTORDoCKWIuRWepUE3KNdJ38SeuK1K7H+O6ZRaVoGYUvr/t/yPDuyNDx64m lH6fS7rP99LFmwb0CW2zarjaYf3E4HEuA8GptHbxhTl+olqC4mlYyxz1QzRcbkY5P4Y+ KWSNqB3vGq8pTB05FbZas2l6cwVkpcaHf4/F9NHjehxE3BCXga+AfH8reOH0MO3sn+/g ZZEtRVBJxNpI1UNXIbYlNt1yJWaKvtqK5j1WxXJU0BgjlH8zad46yM4UhZ1AN049ovQg qmVFxK4RqgIGM3WZhcntR+Mv7W64jLUOKYJn3d37z3aClvn3mFWvJq258Cb3hKFggwco Lt3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@cmpxchg.org header.s=x header.b=fITt8iJT; 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=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3-v6si5860082plp.471.2018.04.20.13.47.09; Fri, 20 Apr 2018 13:47: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; dkim=fail header.i=@cmpxchg.org header.s=x header.b=fITt8iJT; 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=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752722AbeDTUm4 (ORCPT + 99 others); Fri, 20 Apr 2018 16:42:56 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:52282 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751228AbeDTUmy (ORCPT ); Fri, 20 Apr 2018 16:42:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmpxchg.org ; s=x; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gqeCfhZ+I/DmjHt7xg7+NveAtkYIXyAoOku859mXGtM=; b=fITt8iJTv4uyonruVTXfYalGyI Q2uo8llYV2fHXZEfSbzNqOC4JySlANEmcgTGcUWjUIqfChneLOImiT0pWyJbClLOeY5rxWgYzUe38 RYMgK4dzMifpJBLnyLIMLoQFoAHasJY2qMmzGPfIqWaRhPkM6OJ2hGM2RFzZQEy19N2g=; Date: Fri, 20 Apr 2018 16:44:29 -0400 From: Johannes Weiner To: Roman Gushchin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kernel-team@fb.com, Michal Hocko , Vladimir Davydov , Tejun Heo Subject: Re: [PATCH 1/2] mm: introduce memory.min Message-ID: <20180420204429.GA24563@cmpxchg.org> References: <20180420163632.3978-1-guro@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180420163632.3978-1-guro@fb.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roman, this looks cool, and the implementation makes sense to me, so the feedback I have is just smaller stuff. On Fri, Apr 20, 2018 at 05:36:31PM +0100, Roman Gushchin wrote: > Memory controller implements the memory.low best-effort memory > protection mechanism, which works perfectly in many cases and > allows protecting working sets of important workloads from > sudden reclaim. > > But it's semantics has a significant limitation: it works its > only until there is a supply of reclaimable memory. s/until/as long as/ Maybe "as long as there is an unprotected supply of reclaimable memory from other groups"? > This makes it pretty useless against any sort of slow memory > leaks or memory usage increases. This is especially true > for swapless systems. If swap is enabled, memory soft protection > effectively postpones problems, allowing a leaking application > to fill all swap area, which makes no sense. > The only effective way to guarantee the memory protection > in this case is to invoke the OOM killer. This makes it sound like it has no purpose at all. But like with memory.high, the point is to avoid the kernel OOM killer, which knows jack about how the system is structured, and instead allow userspace management software to monitor MEMCG_LOW and make informed decisions. memory.min again is the fail-safe for memory.low, not the primary way of implementing guarantees. > @@ -297,7 +297,14 @@ static inline bool mem_cgroup_disabled(void) > return !cgroup_subsys_enabled(memory_cgrp_subsys); > } > > -bool mem_cgroup_low(struct mem_cgroup *root, struct mem_cgroup *memcg); > +enum mem_cgroup_protection { > + MEM_CGROUP_UNPROTECTED, > + MEM_CGROUP_PROTECTED_LOW, > + MEM_CGROUP_PROTECTED_MIN, > +}; These look a bit unwieldy. How about MEMCG_PROT_NONE, MEMCG_PROT_LOW, MEMCG_PROT_HIGH, > +enum mem_cgroup_protection > +mem_cgroup_protected(struct mem_cgroup *root, struct mem_cgroup *memcg); Please don't wrap at the return type, wrap the parameter list instead. > int mem_cgroup_try_charge(struct page *page, struct mm_struct *mm, > gfp_t gfp_mask, struct mem_cgroup **memcgp, > @@ -756,6 +763,12 @@ static inline void memcg_memory_event(struct mem_cgroup *memcg, > { > } > > +static inline bool mem_cgroup_min(struct mem_cgroup *root, > + struct mem_cgroup *memcg) > +{ > + return false; > +} > + > static inline bool mem_cgroup_low(struct mem_cgroup *root, > struct mem_cgroup *memcg) > { The real implementation has these merged into the single mem_cgroup_protected(). Probably a left-over from earlier versions? It's always a good idea to build test the !CONFIG_MEMCG case too. > @@ -5685,44 +5723,71 @@ struct cgroup_subsys memory_cgrp_subsys = { > * for next usage. This part is intentionally racy, but it's ok, > * as memory.low is a best-effort mechanism. > */ > -bool mem_cgroup_low(struct mem_cgroup *root, struct mem_cgroup *memcg) > +enum mem_cgroup_protection > +mem_cgroup_protected(struct mem_cgroup *root, struct mem_cgroup *memcg) Please fix the wrapping here too. > @@ -2525,12 +2525,29 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc) > unsigned long reclaimed; > unsigned long scanned; > > - if (mem_cgroup_low(root, memcg)) { > + switch (mem_cgroup_protected(root, memcg)) { > + case MEM_CGROUP_PROTECTED_MIN: > + /* > + * Hard protection. > + * If there is no reclaimable memory, OOM. > + */ > + continue; > + > + case MEM_CGROUP_PROTECTED_LOW: Please drop that newline after continue. > + /* > + * Soft protection. > + * Respect the protection only until there is > + * a supply of reclaimable memory. Same feedback here as in the changelog: s/until/as long as/ Maybe "as long as there is an unprotected supply of reclaimable memory from other groups"? > + */ > if (!sc->memcg_low_reclaim) { > sc->memcg_low_skipped = 1; > continue; > } > memcg_memory_event(memcg, MEMCG_LOW); > + break; > + > + case MEM_CGROUP_UNPROTECTED: Please drop that newline after break, too. Thanks! Johannes