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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 3A685C2BB55 for ; Fri, 10 Apr 2020 21:32:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F28B92083E for ; Fri, 10 Apr 2020 21:32:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="A9BBea+d" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F28B92083E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A28978E0065; Fri, 10 Apr 2020 17:32:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D9318E004D; Fri, 10 Apr 2020 17:32:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C6E08E0065; Fri, 10 Apr 2020 17:32:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0109.hostedemail.com [216.40.44.109]) by kanga.kvack.org (Postfix) with ESMTP id 733938E004D for ; Fri, 10 Apr 2020 17:32:21 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3A629824556B for ; Fri, 10 Apr 2020 21:32:21 +0000 (UTC) X-FDA: 76693244082.30.fork74_319bfd9857e28 X-HE-Tag: fork74_319bfd9857e28 X-Filterd-Recvd-Size: 3369 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Fri, 10 Apr 2020 21:32:20 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BABFD20936; Fri, 10 Apr 2020 21:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586554340; bh=0fIlDT5NiITLoRiD3U0UD6TiCwNXseNC8+Gt48gQQF0=; h=Date:From:To:Subject:In-Reply-To:From; b=A9BBea+d8vz8y4lEs15ToCBipFTySyPtWSV/9DZuNrjCJ6/dAsfs6csEfS+DK+Z6I UFHMpNFK9eXUcuc/A2pMbgEgJCaVC3RCqBpm05g4vlgHM1Z42C1f8KkV5T8HPpt+de nbfGP/toxJOUkmPb4mcZu0e8sFeKbIZvd9baDzOo= Date: Fri, 10 Apr 2020 14:32:19 -0700 From: Andrew Morton To: akpm@linux-foundation.org, chris@chrisdown.name, hannes@cmpxchg.org, kuba@kernel.org, linux-mm@kvack.org, mhocko@suse.com, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 02/35] mm, memcg: do not high throttle allocators based on wraparound Message-ID: <20200410213219.Qt50SPoTu%akpm@linux-foundation.org> In-Reply-To: <20200410143047.bf34a933ce1affdc042c7c80@linux-foundation.org> User-Agent: s-nail v14.8.16 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: From: Jakub Kicinski Subject: mm, memcg: do not high throttle allocators based on wraparound 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). [chris@chrisdown.name: changelog] Link: http://lkml.kernel.org/r/20200331152424.GA1019937@chrisdown.name Fixes: e26733e0d0ec ("mm, memcg: throttle allocators based on ancestral memory.high") Signed-off-by: Jakub Kicinski Signed-off-by: Chris Down Acked-by: Michal Hocko Cc: Johannes Weiner Cc: [5.4.x] Signed-off-by: Andrew Morton --- mm/memcontrol.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/memcontrol.c~mm-memcg-do-not-high-throttle-allocators-based-on-wraparound +++ a/mm/memcontrol.c @@ -2336,6 +2336,9 @@ static unsigned long calculate_high_dela 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 _