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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 32C2AC35E04 for ; Tue, 25 Feb 2020 18:40:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E381B218AC for ; Tue, 25 Feb 2020 18:40:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="ERjzs/tX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E381B218AC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 866D36B0006; Tue, 25 Feb 2020 13:40:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EFBF6B0007; Tue, 25 Feb 2020 13:40:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 690116B0008; Tue, 25 Feb 2020 13:40:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 4BCE86B0006 for ; Tue, 25 Feb 2020 13:40:20 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id EFBD4127C for ; Tue, 25 Feb 2020 18:40:19 +0000 (UTC) X-FDA: 76529514600.27.board97_2cae43ef9b1f X-HE-Tag: board97_2cae43ef9b1f X-Filterd-Recvd-Size: 6381 Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com [209.85.219.66]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Tue, 25 Feb 2020 18:40:19 +0000 (UTC) Received: by mail-qv1-f66.google.com with SMTP id q9so129730qvu.7 for ; Tue, 25 Feb 2020 10:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=i2CV/HrBlB038Ie8Qimmh82koD0NdKzml2lxz77LIw8=; b=ERjzs/tXZewLwer9YDYr/IYsZ/pnkPxN3//YU6bP7CHHDRMWHkIbtg/nZJaTXwNmK7 4Qs4eXYUyB3Ezg+amypKAA20yzqDlEMeDIBpWdXMJnLR0PY7mXMKbXfnv97c2RPJisPX mm5VxvL+kqkeqFK9E7EdHKna0JtlAdztQzV/q7yA8TjapZ/6iFqjVEf2XjpalFBXfJY5 qX3jcf2q9XJ5LFRVJQgHZWN8TzNR4va/XA3U7FJ79+PGCItxdnPc4CUAhu+up/bX+Tfn Vfdfg2Pcea2m37AoNJ0Xto0D2JDL0rkW2eLIM8KMNVqsT+PYB2rqxqoqatC4WbAuFM49 3yDg== 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:content-transfer-encoding :in-reply-to; bh=i2CV/HrBlB038Ie8Qimmh82koD0NdKzml2lxz77LIw8=; b=ruLjJwDJpGIRNSGitItEE0LLnqFPzaeDYuVR7GIbv6lMRbr0psvR44NnhDaC4B3ThS SH+WXAx5giybeZ2qv2WoQgMBML2i9MDq2D+xG7UY3Xlgke/XTJNDRtA0gyPSE83n7aN7 LYSRDeu3KYH7ynY/222MEUEBa1/VnIbXqYQrZl0dDG0fJN1dkNbh5rwHAtlCmiJu50f0 LxZspmtI8fTLiREPXHQYJMwLEZEXfNnZG0lDsU0rYAPj4DOPUhlRXiWGBB7QdXo74P+k OgQqjfnQ8u8O2pW51QdCRyQ+arYAfDnbD7wOhVtb6L01Q4teP46wdu4WNnb/U5Nm3Ohh SpOA== X-Gm-Message-State: APjAAAUHohLI2aW/EVmswnr++lQazgUTJTULLj3CmE21w5QRG2DiFwS1 rdKnM7KObM7jc5JN1wMx+5hCUA== X-Google-Smtp-Source: APXvYqykB1tvyK9fp2RnMOVCx8rSnGK9lnKsMu0SxzRDZPYVode1NoBodz4tt48PVsQOPvJqzVRHrQ== X-Received: by 2002:a0c:da08:: with SMTP id x8mr313476qvj.166.1582656018181; Tue, 25 Feb 2020 10:40:18 -0800 (PST) Received: from localhost ([2620:10d:c091:500::1:4d9c]) by smtp.gmail.com with ESMTPSA id u26sm6102857qkk.18.2020.02.25.10.40.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2020 10:40:17 -0800 (PST) Date: Tue, 25 Feb 2020 13:40:14 -0500 From: Johannes Weiner To: Michal =?iso-8859-1?Q?Koutn=FD?= 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 2/3] mm: memcontrol: clean up and document effective low/min calculations Message-ID: <20200225184014.GC10257@cmpxchg.org> References: <20191219200718.15696-1-hannes@cmpxchg.org> <20191219200718.15696-3-hannes@cmpxchg.org> <20200221171024.GA23476@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200221171024.GA23476@blackbody.suse.cz> Content-Transfer-Encoding: quoted-printable 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: Hello Michal, On Fri, Feb 21, 2020 at 06:10:24PM +0100, Michal Koutn=FD wrote: > On Thu, Dec 19, 2019 at 03:07:17PM -0500, Johannes Weiner wrote: > > + * Consider the following example tree: > > * > > + * A A/memory.low =3D 2G, A/memory.current =3D 6G > > + * //\\ > > + * BC DE B/memory.low =3D 3G B/memory.current =3D 2G > > + * C/memory.low =3D 1G C/memory.current =3D 2G > > + * D/memory.low =3D 0 D/memory.current =3D 2G > > + * E/memory.low =3D 10G E/memory.current =3D 0 > > * > > + * and memory pressure is applied, the following memory > > + * distribution is expected (approximately*): > > * > > + * A/memory.current =3D 2G > > + * B/memory.current =3D 1.3G > > + * C/memory.current =3D 0.6G > > + * D/memory.current =3D 0 > > + * E/memory.current =3D 0 > > * > > + * *assuming equal allocation rate and reclaimability > I think the assumptions for this example don't hold (anymore). > Because reclaim rate depends on the usage above protection, the sibling= s > won't be reclaimed equally and so the low_usage proportionality will > change over time and the equilibrium distribution is IMO different (I'm > attaching an Octave script to calculate it). Hm, this example doesn't change with my patch because there is no "floating" protection that gets distributed among the siblings. In my testing with the above parameters, the equilibrium still comes out to roughly this distribution. > As it depends on the initial usage, I don't think there can be given > such a general example (for overcommit). It's just to illustrate the pressure weight, not to reflect each factor that can influence the equilibrium. I think it still has value to gain understanding of how it works, no? > > @@ -6272,12 +6262,63 @@ struct cgroup_subsys memory_cgrp_subsys =3D { > > * for next usage. This part is intentionally racy, but it's ok, > > * as memory.low is a best-effort mechanism. > Although it's a different issue but since this updates the docs I'm > mentioning it -- we treat memory.min the same, i.e. it's subject to the > same race, however, it's not meant to be best effort. I didn't look int= o > outcomes of potential misaccounting but the comment seems to miss impac= t > on memory.min protection. Yeah I think we can delete that bit. > > @@ -6292,52 +6333,29 @@ enum mem_cgroup_protection mem_cgroup_protect= ed(struct mem_cgroup *root, > > [...] > > + if (parent =3D=3D root) { > > + memcg->memory.emin =3D memcg->memory.min; > > + memcg->memory.elow =3D memcg->memory.low; > > + goto out; > > } > Shouldn't this condition be 'if (parent =3D=3D root_mem_cgroup)'? (I.e.= 1st > level takes direct input, but 2nd and further levels redistribute only > what they really got from parent.) I believe we cleared this up in the parallel thread, but just in case: reclaim can happen due to a memory.max set lower in the tree. memory.low propagation is always relative from the reclaim scope, not the system-wide root cgroup.