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 ABD6FC433DB for ; Mon, 22 Feb 2021 17:41:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1805164DBD for ; Mon, 22 Feb 2021 17:41:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1805164DBD 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 86EEC6B0078; Mon, 22 Feb 2021 12:41:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 81A058D0002; Mon, 22 Feb 2021 12:41:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BA4B8D0001; Mon, 22 Feb 2021 12:41:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 528BA6B0078 for ; Mon, 22 Feb 2021 12:41:04 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1172140C3 for ; Mon, 22 Feb 2021 17:41:04 +0000 (UTC) X-FDA: 77846619648.21.B43E10F Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf26.hostedemail.com (Postfix) with ESMTP id E4CD04080F46 for ; Mon, 22 Feb 2021 17:40:58 +0000 (UTC) IronPort-SDR: FcYzLedav7oIrIpRN9lLAg1PY2V9hnBnHfWVKSq0zL5f43t/t96hyNeRFYg6qdUtT5wHBmA+nW TM39NvDZQ5kA== X-IronPort-AV: E=McAfee;i="6000,8403,9903"; a="269467236" X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="269467236" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 09:41:01 -0800 IronPort-SDR: x97tSTHLw4Sn7xuu5atwz6IoejJVqQUYJFViPiDxfERnyagSlf47L+CRxTykHeoiv9PjHZqie/ loEFB6DK4FDw== X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="389941175" Received: from schen9-mobl.amr.corp.intel.com ([10.251.12.88]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 09:41:00 -0800 Subject: Re: [PATCH v2 2/3] mm: Force update of mem cgroup soft limit tree on usage excess 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> From: Tim Chen Message-ID: Date: Mon, 22 Feb 2021 09:41:00 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Stat-Signature: mr895qa5impgqpmg4hfs647mgmmcaqz6 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E4CD04080F46 Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf26; identity=mailfrom; envelope-from=""; helo=mga05.intel.com; client-ip=192.55.52.43 X-HE-DKIM-Result: none/none X-HE-Tag: 1614015658-484340 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/22/21 12:40 AM, Michal Hocko wrote: > On Fri 19-02-21 10:59:05, Tim Chen wrote: occurrence. >>> >>> 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. > > Well this all depends on when the the soft limit reclaim triggeres. In > other words how often you see the global memory reclaim. If we have a > memcg with a sufficient excess then this will work mostly fine. I was more > worried about a case when you have memcgs just slightly over the limit > and the global memory pressure is a regular event. You can easily end up > bouncing memcgs off and on the tree in a rapid fashion. > If you are concerned about such a case, we can add an excess threshold, say 4 MB (or 1024 4K pages), before we trigger a forced update. You think that will cover this concern? >>> >>> One way around that would be to lower the SOFTLIMIT_EVENTS_TARGET. Have >>> you tried that? Do we even need a separate treshold for soft limit, why >>> cannot we simply update the tree each MEM_CGROUP_TARGET_THRESH? >>> >> >> Lowering the threshold is a band aid that really doesn't fix the problem. >> I found that if the cgroup touches the memory infrequently enough, you >> could still miss the update of it. And in the mean time, you are updating >> things a lot more frequently with added overhead. > > Yes, I agree this is more of a workaround than a fix but I would rather > go and touch the threshold which is simply bad than play more tricks > which can lead to other potential problems. All that for a feature which > is rarely used and quite problematic in itself. Not sure what Johannes > thinks about that. > I actually have tried adjusting the threshold but found that it doesn't work well for the case with unenven memory access frequency between cgroups. The soft limit for the low memory event cgroup could creep up quite a lot, exceeding the soft limit by hundreds of MB, even if I drop the SOFTLIMIT_EVENTS_TARGET from 1024 to something like 8. Tim