From patchwork Tue Aug 4 00:03:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 266772 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=BAYES_00,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 E93CFC433E1 for ; Tue, 4 Aug 2020 00:03:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 025322086A for ; Tue, 4 Aug 2020 00:03:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596499404; bh=N6QHjdb/DQV2ZLM6TQWJrwqac5QwLsnE85j4EcwohBk=; h=Date:From:To:Subject:List-ID:From; b=Ui+5ynOtUfwPRTGp8yyTacYr6JJhF6t7w2WJsdQ/P1sSZ1VNQ+HblqPpLTYTO3LSg A/luw3GSHw+SiTnY2rCjXGRAYCqact9SR3UdDJTyW0DldERv1kpOlsCQa21sCFOV6g pMKqPSkNW5Sd+buhGiIlLmcbY4if/DxmoSo/AUzQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728037AbgHDADX (ORCPT ); Mon, 3 Aug 2020 20:03:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:52158 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726725AbgHDADX (ORCPT ); Mon, 3 Aug 2020 20:03:23 -0400 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 52C6020786; Tue, 4 Aug 2020 00:03:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596499402; bh=N6QHjdb/DQV2ZLM6TQWJrwqac5QwLsnE85j4EcwohBk=; h=Date:From:To:Subject:From; b=kMW+ps94OhlEa8R7nMFhRDGvbaNhDBr8rikL624j+ItSddeZtRx07h+e6cTAB8NC9 svrZdf6IF4zej4YQKtx1zyLYXHLB7HjWqo+wIUZUA7kgqYsJy2Gy7pdAX4zKDFQPOk pwDhVzJGX8fGbZJIAM/AK6eYE/HSifQILPYX4dWs= Date: Mon, 03 Aug 2020 17:03:21 -0700 From: akpm@linux-foundation.org To: guro@fb.com, hannes@cmpxchg.org, mhocko@suse.com, mkoutny@suse.com, mm-commits@vger.kernel.org, stable@vger.kernel.org, tj@kernel.org Subject: + mm-fix-protection-usage-propagation.patch added to -mm tree Message-ID: <20200804000321.PxQ1KP_0d%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: mm/page_counter.c: fix protection usage propagation has been added to the -mm tree. Its filename is mm-fix-protection-usage-propagation.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-fix-protection-usage-propagation.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-fix-protection-usage-propagation.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Michal Koutný Subject: mm/page_counter.c: fix protection usage propagation 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. 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. The fix is simply updating children_low_usage in respective ancestors also in the charging path. Link: http://lkml.kernel.org/r/20200803153231.15477-1-mhocko@kernel.org Fixes: 230671533d64 ("mm: memory.low hierarchical behavior") Signed-off-by: Michal Koutný Signed-off-by: Michal Hocko Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Roman Gushchin Cc: Tejun Heo Cc: [4.18+] Signed-off-by: Andrew Morton --- mm/page_counter.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/page_counter.c~mm-fix-protection-usage-propagation +++ a/mm/page_counter.c @@ -72,7 +72,7 @@ void page_counter_charge(struct page_cou 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 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 *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.