From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5A27C43603 for ; Fri, 20 Dec 2019 04:29:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 77BF221D7D for ; Fri, 20 Dec 2019 04:29:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="A0aDjvyH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77BF221D7D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 096BA8E018C; Thu, 19 Dec 2019 23:29:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 01F248E0184; Thu, 19 Dec 2019 23:29:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E01908E018C; Thu, 19 Dec 2019 23:29:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id C60048E0184 for ; Thu, 19 Dec 2019 23:29:26 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 70AC033C4 for ; Fri, 20 Dec 2019 04:29:26 +0000 (UTC) X-FDA: 76284240732.10.grain24_182ac8f28ca3b X-HE-Tag: grain24_182ac8f28ca3b X-Filterd-Recvd-Size: 4926 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Dec 2019 04:29:25 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id g17so8093554wro.2 for ; Thu, 19 Dec 2019 20:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=yRRnujDGn+DKixV01iK1kQ9R1Hb6ldjE0k/esoxvtVg=; b=A0aDjvyHIdJhLqDtp99NMEN/80Jxl6wvh+lvb7+lH/qp6guNY98LBPwD0tcfMsFfk6 g6s7MAEi2vlSscOrVsRDLJm1UzTKiVag9IlTkT+joi/WQhHf0NJ5d4IHH/ekSVlZyili wBB35uFGXtDvGNNUvJK8qm8EHrv+BJC+5cCJs= 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=yRRnujDGn+DKixV01iK1kQ9R1Hb6ldjE0k/esoxvtVg=; b=HpVNu0SeKSND/gdma/7nAuWZ727tFXwzCwp73ePsF5YxEG4xKds6ZVUKcvwrpWo0KI Hgg0tMp/Lmohd6L1H04G2rI1QWz/n5MWMuCph5sNOKTsVpxT7LV4d3ePSqor1DR5mfeJ BRCLPQyvnhevN0W6V9KE9NI3Nz3H2RuEpTpZi0jS3lvdKpxqSmgHeyBUBWQk9mNmDfZY rWkph+tT7ksYDQaoiRh6NXh89ThjchzNAZC/1LB4U9q3HRTFWWYQIBPTAPsbAsiapEyy xRb1L7u0PrpNbZkJjhWoYckloxCyigtjFj2dA1G6glvUKlXT1QO7v1DRB6P6if9DaqgR l2gg== X-Gm-Message-State: APjAAAWt2VMwi2tWjmFaaXnXoy0vlLjKcBQi04R9dilQGrPJOpPVe3sB O2+wp914GRSBYJBo86gcXjdMbg== X-Google-Smtp-Source: APXvYqwLRAXyAkhlCKztZpOXJtBJaYt9dagkawITr0ZMAIpf7TA6fhV48XsQuPRBh7oEnf2WLQ3OVQ== X-Received: by 2002:adf:ec83:: with SMTP id z3mr12721685wrn.133.1576816164528; Thu, 19 Dec 2019 20:29:24 -0800 (PST) Received: from localhost ([2a01:4b00:8432:8a00:63de:dd93:20be:f460]) by smtp.gmail.com with ESMTPSA id x1sm8274608wru.50.2019.12.19.20.29.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Dec 2019 20:29:24 -0800 (PST) Date: Fri, 20 Dec 2019 04:29:23 +0000 From: Chris Down To: Johannes Weiner Cc: Andrew Morton , Roman Gushchin , Michal Hocko , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 0/3] mm: memcontrol: recursive memory protection Message-ID: <20191220042923.GA388018@chrisdown.name> References: <20191219200718.15696-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20191219200718.15696-1-hannes@cmpxchg.org> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Johannes Weiner writes: >Changes since v1: >- improved Changelogs based on the discussion with Roman. Thanks! >- fix div0 when recursive & fixed protection is combined >- fix an unused compiler warning > >The current memory.low (and memory.min) semantics require protection >to be assigned to a cgroup in an untinterrupted chain from the >top-level cgroup all the way to the leaf. > >In practice, we want to protect entire cgroup subtrees from each other >(system management software vs. workload), but we would like the VM to >balance memory optimally *within* each subtree, without having to make >explicit weight allocations among individual components. The current >semantics make that impossible. > >This patch series extends memory.low/min such that the knobs apply >recursively to the entire subtree. Users can still assign explicit >protection to subgroups, but if they don't, the protection set by the >parent cgroup will be distributed dynamically such that children >compete freely - as if no memory control were enabled inside the >subtree - but enjoy protection from neighboring trees. Thanks, from experience working with these semantics in userspace, I agree that this design makes it easier to configure the protections in a way that is meaningful. For the series: Acked-by: Chris Down >Patch #1 fixes an existing bug that can give a cgroup tree more >protection than it should receive as per ancestor configuration. > >Patch #2 simplifies and documents the existing code to make it easier >to reason about the changes in the next patch. > >Patch #3 finally implements recursive memory protection semantics. Just as an off-topic aside, although I'm sure you already have it in mind, we should definitely make sure to clearly point this out to those in the container management tooling space who are in the process of moving to support/default to v2. For example, I wonder about CoreOS' systemwide strategy around memory management and whether it can benefit from this.