From patchwork Mon Aug 3 15:32:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 11698337 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 26F1013B6 for ; Mon, 3 Aug 2020 15:32:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E8F7C20781 for ; Mon, 3 Aug 2020 15:32:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8F7C20781 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 0EB0F8D0108; Mon, 3 Aug 2020 11:32:47 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 09BBF8D0081; Mon, 3 Aug 2020 11:32:47 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA5688D0108; Mon, 3 Aug 2020 11:32:46 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id D4E718D0081 for ; Mon, 3 Aug 2020 11:32:46 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 92A13180AD801 for ; Mon, 3 Aug 2020 15:32:46 +0000 (UTC) X-FDA: 77109649932.28.self44_5d140f626f9e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 6025F6C1D for ; Mon, 3 Aug 2020 15:32:46 +0000 (UTC) X-Spam-Summary: 1,0,0,68a2bd9c7768e6e6,d41d8cd98f00b204,mstsxfx@gmail.com,,RULES_HIT:41:152:355:379:541:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:2897:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:4041:4184:4321:5007:6261:7576:7903:10004:10400:10450:10455:11026:11232:11658:11914:12043:12048:12295:12296:12297:12438:12517:12519:12555:12663:12679:12895:12986:13071:13161:13229:13870:13894:14093:14096:14097:14180:14181:14394:14659:14721:19904:19999:21060:21067:21080:21444:21451:21627:21740:30054:30090,0,RBL:209.85.128.65:@gmail.com:.lbl8.mailshell.net-66.100.201.100 62.50.0.100;04y87nexpu56kheye9k8sd7fi6t8soctxcinmqj5wf5unn18a3swfzh8fsxak6u.u8c7huj5rwt53qjr1unpd976r36yidtdj4dt31uykx1g69frdjctedbk1khaqdp.o-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime :23,LUA_ X-HE-Tag: self44_5d140f626f9e X-Filterd-Recvd-Size: 4967 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Mon, 3 Aug 2020 15:32:45 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id g8so4815wmk.3 for ; Mon, 03 Aug 2020 08:32:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=aAEEBYH/RNE6F6eih4Xf8kJGXqfcNHHmi9tjJ8DCSlI=; b=ktokdWxrIZ90HXutPGksm41gOb8YF1+N6wTbQnX7cojElqE9m9Yjzgbad0TyOeShBd Hb2kIUb30F3XLcy5n5lJGt2miLlz981rAupOTH1oyRygFh0ghTRnATIAL8vxTyXygKuz WhlagQMCYPNgeSOvU5ZHt6KODWjzCzCL9d9sGff6LcMvTkW9z3asZssf0UHX6ibiBav3 UOgoG7DcD/pd/HmR7ozVNnHHw7uzMOg0u4Hro4CEiwX23iRAvBWV56pb09+C9IgrdW6d x6HDxBuOSwp3ePi0vZ95aXgkTHAMtXd34lBfTSPEo6GN2g+X03R4G1fp7Y/CVU2XAF4Y lAkA== X-Gm-Message-State: AOAM53113duUeBI0S9t2zs/MYBEGWqRzu3cqAV2fsQX4AEnxead22LEL 412qeaZPrpd33uXVBjq8JiU= X-Google-Smtp-Source: ABdhPJyjogI7x4EjysRPYcFwG3urMjXbnPLRiwE52sPayUyavtnb6nVIzYghbVaf/rmvG/kmOb0Rfg== X-Received: by 2002:a1c:ba83:: with SMTP id k125mr515975wmf.160.1596468764859; Mon, 03 Aug 2020 08:32:44 -0700 (PDT) Received: from tiehlicka.suse.cz (ip-37-188-169-187.eurotel.cz. [37.188.169.187]) by smtp.gmail.com with ESMTPSA id w1sm25562444wmc.18.2020.08.03.08.32.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2020 08:32:44 -0700 (PDT) From: Michal Hocko To: Johannes Weiner , Roman Gushchin , Andrew Morton , Michal Koutny Cc: Tejun Heo , , LKML , Michal Hocko Subject: [PATCH] mm: Fix protection usage propagation Date: Mon, 3 Aug 2020 17:32:31 +0200 Message-Id: <20200803153231.15477-1-mhocko@kernel.org> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 X-Rspamd-Queue-Id: 6025F6C1D X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: Michal Koutný When workload runs in cgroups that aren't directly below root cgroup and their parent specifies reclaim protection, it may end up ineffective. The reason is that propagate_protected_usage() is not called in all hierarchy up. All the protected usage is incorrectly accumulated in the workload's parent. This means that siblings_low_usage is overestimated and effective protection underestimated. Even though it is transitional phenomenon (uncharge path does correct propagation and fixes the wrong children_low_usage), it can undermine the indended protection unexpectedly. The fix is simply updating children_low_usage in respective ancestors also in the charging path. Fixes: 230671533d64 ("mm: memory.low hierarchical behavior") Cc: stable # 4.18+ Signed-off-by: Michal Koutný Acked-by: Michal Hocko Acked-by: Roman Gushchin --- Hi, I am sending this patch on behalf of Michal Koutny who is currently on vacation and didn't get to post it before he left. We have noticed this problem while seeing a swap out in a descendant of a protected memcg (intermediate node) while the parent was conveniently under its protection limit and the memory pressure was external to that hierarchy. Michal has pinpointed this down to the wrong siblings_low_usage which led to the unwanted reclaim. I am adding my ack directly in this submission. mm/page_counter.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/page_counter.c b/mm/page_counter.c index c56db2d5e159..b4663844c9b3 100644 --- a/mm/page_counter.c +++ b/mm/page_counter.c @@ -72,7 +72,7 @@ void page_counter_charge(struct page_counter *counter, unsigned long nr_pages) long new; new = atomic_long_add_return(nr_pages, &c->usage); - propagate_protected_usage(counter, new); + propagate_protected_usage(c, new); /* * This is indeed racy, but we can live with some * inaccuracy in the watermark. @@ -116,7 +116,7 @@ bool page_counter_try_charge(struct page_counter *counter, new = atomic_long_add_return(nr_pages, &c->usage); if (new > c->max) { atomic_long_sub(nr_pages, &c->usage); - propagate_protected_usage(counter, new); + propagate_protected_usage(c, new); /* * This is racy, but we can live with some * inaccuracy in the failcnt. @@ -125,7 +125,7 @@ bool page_counter_try_charge(struct page_counter *counter, *fail = c; goto failed; } - propagate_protected_usage(counter, new); + propagate_protected_usage(c, new); /* * Just like with failcnt, we can live with some * inaccuracy in the watermark.