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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 DD13AC433E0 for ; Sat, 20 Feb 2021 16:23:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4F06464ED7 for ; Sat, 20 Feb 2021 16:23:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F06464ED7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 640E86B0006; Sat, 20 Feb 2021 11:23:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CA236B006C; Sat, 20 Feb 2021 11:23:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 492556B006E; Sat, 20 Feb 2021 11:23:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 2D92B6B0006 for ; Sat, 20 Feb 2021 11:23:24 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E4D6FA764 for ; Sat, 20 Feb 2021 16:23:23 +0000 (UTC) X-FDA: 77839166286.19.7443F28 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf05.hostedemail.com (Postfix) with ESMTP id 855B8E00010C for ; Sat, 20 Feb 2021 16:23:21 +0000 (UTC) IronPort-SDR: bSIOoIhfEFqizqAWPGUjzGQQ5SrN5r3VVaIJ63RNeQhCMRuFY40f/VonOtqwyK+vGVnSAbXkTu 0K/AmYMD1f8A== X-IronPort-AV: E=McAfee;i="6000,8403,9901"; a="163274257" X-IronPort-AV: E=Sophos;i="5.81,193,1610438400"; d="scan'208";a="163274257" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2021 08:23:20 -0800 IronPort-SDR: umqKPvJnXSIFFoaWTBibCca5qVsWhPWL6JAy4xcv1E154Rnw1e7JthfFOHL/gwkdxeOeBtTD89 xRN3KZ6zILFg== X-IronPort-AV: E=Sophos;i="5.81,193,1610438400"; d="scan'208";a="401566446" Received: from schen9-mobl.amr.corp.intel.com ([10.251.12.105]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2021 08:23:20 -0800 Subject: Re: [PATCH v2 2/3] mm: Force update of mem cgroup soft limit tree on usage excess From: Tim Chen To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , Vladimir Davydov , Dave Hansen , Ying Huang , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org References: <06f1f92f1f7d4e57c4e20c97f435252c16c60a27.1613584277.git.tim.c.chen@linux.intel.com> <884d7559-e118-3773-351d-84c02642ca96@linux.intel.com> Message-ID: <0f8117ef-c461-e2be-ea7a-6cbf727c9bb5@linux.intel.com> Date: Sat, 20 Feb 2021 08:23:15 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <884d7559-e118-3773-351d-84c02642ca96@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 855B8E00010C X-Stat-Signature: ek8f15rxiswigt4g1k6ij4qq7eqdf11r Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=mga12.intel.com; client-ip=192.55.52.136 X-HE-DKIM-Result: none/none X-HE-Tag: 1613838201-595612 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 2/19/21 10:59 AM, Tim Chen wrote: > > > On 2/19/21 1:11 AM, Michal Hocko wrote: >> >> Soft limit is evaluated every THRESHOLDS_EVENTS_TARGET * SOFTLIMIT_EVENTS_TARGET. >> If all events correspond with a newly charged memory and the last event >> was just about the soft limit boundary then we should be bound by 128k >> pages (512M and much more if this were huge pages) which is a lot! >> I haven't realized this was that much. Now I see the problem. This would >> be a useful information for the changelog. >> >> Your fix is focusing on the over-the-limit boundary which will solve the >> problem but wouldn't that lead to to updates happening too often in >> pathological situation when a memcg would get reclaimed immediatelly? > > Not really immediately. The memcg that has the most soft limit excess will > be chosen for page reclaim, which is the way it should be. > It is less likely that a memcg that just exceeded > the soft limit becomes the worst offender immediately. With the fix, we make > sure that it is on the bad guys list and will not be ignored and be chosen > eventually for reclaim. It will not sneakily increase its memory usage > slowly. > I should also mention that the forced update is only performed once when the memcg first exceeded the soft limit as we check whether the memcg is already in the soft limit tree due to the !mz->on_tree check. + if (mz && !mz->on_tree && soft_limit_excess(mz->memcg) > 0) + force_update = true; So the update overhead is very low. Tim