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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 E09EDC433DB for ; Thu, 18 Feb 2021 19:13:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2B0B764EB9 for ; Thu, 18 Feb 2021 19:13:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B0B764EB9 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 66CD76B0006; Thu, 18 Feb 2021 14:13:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 641936B006C; Thu, 18 Feb 2021 14:13:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57FEB6B006E; Thu, 18 Feb 2021 14:13:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id 430156B0006 for ; Thu, 18 Feb 2021 14:13:11 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0625C1E14 for ; Thu, 18 Feb 2021 19:13:11 +0000 (UTC) X-FDA: 77832336582.01.34C42D8 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf10.hostedemail.com (Postfix) with ESMTP id 35F764080F44 for ; Thu, 18 Feb 2021 19:13:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1613675586; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2LEQzo8vyQpA89Pwawhl0KdWDVli2brjorL41NH4bg0=; b=q5SAQAr80eSFU1sPIy6CPtTyAaCdMpHwCM7Gkx4DMHmqb7iSUZx2XB3g4/RHdI4czipuk2 sGettzMqvcBp7SCmWZYw0Y5AcV8QnfUtNNaVuiascQ56cekbOUDDKk2RY/AWErk/j5iQ8c p2/P60C3SgKfPh9tyOlO+mt9MUgS07U= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8EDA4ACD4; Thu, 18 Feb 2021 19:13:06 +0000 (UTC) Date: Thu, 18 Feb 2021 20:13:05 +0100 From: Michal Hocko To: Tim Chen Cc: Andrew Morton , Johannes Weiner , Vladimir Davydov , Dave Hansen , Ying Huang , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] mm: Fix dropped memcg from mem cgroup soft limit tree Message-ID: References: <8d35206601ccf0e1fe021d24405b2a0c2f4e052f.1613584277.git.tim.c.chen@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: ru7uat3fm7dda9u5tqzxxwpabizmwry9 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 35F764080F44 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf10; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613675586-49021 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 Thu 18-02-21 10:30:20, Tim Chen wrote: > > > 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. I see. My apology for suspecting you from ignoring my review. > 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. It would be great to see more details. > 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. I would still prefer to handle that in the soft limit reclaim path and check each memcg for the soft limit reclaim excess before the reclaim. > 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. I will ack and suggest Fixes. > > Thanks. > > Tim -- Michal Hocko SUSE Labs