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 1DC38C433DB for ; Thu, 18 Feb 2021 18:30:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D69664E2F for ; Thu, 18 Feb 2021 18:30:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D69664E2F 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 C309D6B0006; Thu, 18 Feb 2021 13:30:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE0506B006C; Thu, 18 Feb 2021 13:30:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF7956B006E; Thu, 18 Feb 2021 13:30:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 9A1836B0006 for ; Thu, 18 Feb 2021 13:30:41 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5BE6D8249980 for ; Thu, 18 Feb 2021 18:30:41 +0000 (UTC) X-FDA: 77832229482.27.5197448 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf09.hostedemail.com (Postfix) with ESMTP id 94F1560024A9 for ; Thu, 18 Feb 2021 18:30:36 +0000 (UTC) IronPort-SDR: yb9uQZ42uc3ZlKshJxoztDhxYsVwriY0ck9ogD7YA+X8Hr6qni2cl5GKQqx3NXBRC0yKmmSykS XQplUnFiUTyw== X-IronPort-AV: E=McAfee;i="6000,8403,9899"; a="171278623" X-IronPort-AV: E=Sophos;i="5.81,187,1610438400"; d="scan'208";a="171278623" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2021 10:30:27 -0800 IronPort-SDR: K3prdcyMQiILvxrHbSlBhLyrBhdsusQb3Ie+7kLhrXL3PlDG9elq+aDuhFcd4h4iwFlph3eae9 lRpPRtrwhOkQ== X-IronPort-AV: E=Sophos;i="5.81,187,1610438400"; d="scan'208";a="428315976" Received: from schen9-mobl.amr.corp.intel.com ([10.254.101.217]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2021 10:30:26 -0800 Subject: Re: [PATCH v2 1/3] mm: Fix dropped memcg from mem cgroup soft limit tree 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: <8d35206601ccf0e1fe021d24405b2a0c2f4e052f.1613584277.git.tim.c.chen@linux.intel.com> From: Tim Chen Message-ID: Date: Thu, 18 Feb 2021 10:30:20 -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-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 94F1560024A9 X-Stat-Signature: ydd5g8s6g1jx3td6hpd4dk54h7gs4y88 Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mga18.intel.com; client-ip=134.134.136.126 X-HE-DKIM-Result: none/none X-HE-Tag: 1613673036-489976 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/18/21 12:24 AM, Michal Hocko wrote: > > I have already acked this patch in the previous version along with Fixes > tag. It seems that my review feedback has been completely ignored also > for other patches in this series. Michal, My apology. Our mail system screwed up and there are some mail missing from our mail system that I completely missed your mail. Only saw them now after I looked into the lore.kernel.org. Responding to your comment: >Have you observed this happening in the real life? I do agree that the >threshold based updates of the tree is not ideal but the whole soft >reclaim code is far from optimal. So why do we care only now? The >feature is essentially dead and fine tuning it sounds like a step back >to me. Yes, I did see the issue mentioned in patch 2 breaking soft limit reclaim for cgroup v1. There are still some of our customers using cgroup v1 so we will like to fix this if possible. For patch 3 regarding the uncharge_batch, it is more of an observation that we should uncharge in batch of same node and not prompted by actual workload. Thinking more about this, the worst that could happen is we could have some entries in the soft limit tree that overestimate the memory used. The worst that could happen is a soft page reclaim on that cgroup. The overhead from extra memcg event update could be more than a soft page reclaim pass. So let's drop patch 3 for now. Let me know if you will like me to resend patch 1 with the fixes tag for commit 4e41695356fb ("memory controller: soft limit reclaim on contention") and if there are any changes I should make for patch 2. Thanks. Tim