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=-7.0 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 C5454C43331 for ; Tue, 31 Mar 2020 15:57:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 911B4212CC for ; Tue, 31 Mar 2020 15:57:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 911B4212CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 14A5B6B0032; Tue, 31 Mar 2020 11:57:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FC1F6B0037; Tue, 31 Mar 2020 11:57:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 011A06B006C; Tue, 31 Mar 2020 11:57:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id D9C2F6B0032 for ; Tue, 31 Mar 2020 11:57:56 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A4F525DDA for ; Tue, 31 Mar 2020 15:57:56 +0000 (UTC) X-FDA: 76656113352.02.jam41_2835e68371526 X-HE-Tag: jam41_2835e68371526 X-Filterd-Recvd-Size: 4591 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Tue, 31 Mar 2020 15:57:56 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id 65so26690887wrl.1 for ; Tue, 31 Mar 2020 08:57:56 -0700 (PDT) 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=ajlETTQNKzy9g6KlAay+lUFrUJ8HMEJhr2C6BEcUd6w=; b=uU/LV5SbIx/bQzozFAwDUquLd6uQUD/6YyOLm2ssTNkWde3813TjtQyNFprU21k532 Ia+Igtn0em84a0yAhGsgU+33GLJdIyS6DCiLLmBkhZBFBOz1McmYEZu0u91VgEYCmINK ud8taxAvu+vEOh6c+zZUrmB08l2i5ZTMbk6wDhkZcb2fR2jQuf0L7fsI1VDQWqOwpJKL rwz1f3qis3HeFR3DA1j6I0SpDe8hqWWfWnMbrJK+vFwWi6VU0Vx6AAzNFTG/e9zpe2yx JOR5R5U5UqEOAz9JLCloGAXZDtgytm0jpppWVTec/dTPOcT1/ztzv8FNXZ1kHaH6G068 0qzA== X-Gm-Message-State: ANhLgQ0+6igUs66nEgeQ/935OKrAV90PW9dCsYXfcs/uuuy/E/TsRX27 qX1/j5SxM4mN1DbCJzt/04w= X-Google-Smtp-Source: ADFU+vusVC+kAxIUO0/1NOkFjptxiMjtwlkiI5H3n9XFo9Un/LqGu0X+aapUXnBl+Pj62yb15HdDLw== X-Received: by 2002:adf:e848:: with SMTP id d8mr20629742wrn.209.1585670275039; Tue, 31 Mar 2020 08:57:55 -0700 (PDT) Received: from localhost (ip-37-188-180-223.eurotel.cz. [37.188.180.223]) by smtp.gmail.com with ESMTPSA id u13sm4272535wmm.32.2020.03.31.08.57.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2020 08:57:54 -0700 (PDT) Date: Tue, 31 Mar 2020 17:57:52 +0200 From: Michal Hocko To: Chris Down Cc: Andrew Morton , Johannes Weiner , Jakub Kicinski , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] mm, memcg: Do not high throttle allocators based on wraparound Message-ID: <20200331155752.GN30449@dhcp22.suse.cz> References: <20200331152424.GA1019937@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331152424.GA1019937@chrisdown.name> 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: On Tue 31-03-20 16:24:24, Chris Down wrote: > From: Jakub Kicinski > > If a cgroup violates its memory.high constraints, we may end > up unduly penalising it. For example, for the following hierarchy: > > A: max high, 20 usage > A/B: 9 high, 10 usage > A/C: max high, 10 usage > > We would end up doing the following calculation below when calculating > high delay for A/B: > > A/B: 10 - 9 = 1... > A: 20 - PAGE_COUNTER_MAX = 21, so set max_overage to 21. > > This gets worse with higher disparities in usage in the parent. > > I have no idea how this disappeared from the final version of the patch, > but it is certainly Not Good(tm). This wasn't obvious in testing > because, for a simple cgroup hierarchy with only one child, the result > is usually roughly the same. It's only in more complex hierarchies that > things go really awry (although still, the effects are limited to a > maximum of 2 seconds in schedule_timeout_killable at a maximum). I find this paragraph rather confusing. This is essentially an unsigned underflow when any of the memcg up the hierarchy is below the high limit, right? There doesn't really seem anything complex in such a hierarchy. > [chris@chrisdown.name: changelog] > > Fixes: e26733e0d0ec ("mm, memcg: throttle allocators based on ancestral memory.high") > Signed-off-by: Jakub Kicinski > Signed-off-by: Chris Down > Cc: Johannes Weiner > Cc: stable@vger.kernel.org # 5.4.x To the patch Acked-by: Michal Hocko > --- > mm/memcontrol.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index eecf003b0c56..75a978307863 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2336,6 +2336,9 @@ static unsigned long calculate_high_delay(struct mem_cgroup *memcg, > usage = page_counter_read(&memcg->memory); > high = READ_ONCE(memcg->high); > > + if (usage <= high) > + continue; > + > /* > * Prevent division by 0 in overage calculation by acting as if > * it was a threshold of 1 page > -- > 2.26.0 > -- Michal Hocko SUSE Labs