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=-1.0 required=3.0 tests=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 CDC91C761A6 for ; Mon, 17 Feb 2020 13:24:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 90C0F2070B for ; Mon, 17 Feb 2020 13:24:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90C0F2070B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 255536B0005; Mon, 17 Feb 2020 08:24:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 205D06B0006; Mon, 17 Feb 2020 08:24:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F4F46B0007; Mon, 17 Feb 2020 08:24:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id EC7436B0005 for ; Mon, 17 Feb 2020 08:24:47 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7BB44181AEF0B for ; Mon, 17 Feb 2020 13:24:47 +0000 (UTC) X-FDA: 76499689014.16.soda45_81120d0c6d621 X-HE-Tag: soda45_81120d0c6d621 X-Filterd-Recvd-Size: 5428 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Mon, 17 Feb 2020 13:24:46 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id p9so17140825wmc.2 for ; Mon, 17 Feb 2020 05:24:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5dkQgPE9L5LB87LYvgYERUBPRBzO7AwTWjajMNSOj1k=; b=qicZQtXm0JlDWnjlsM6epTPTLyyeW9RmvoMFchq5eN7tkTYOTMOXnOiQBxdp98zBS+ +yD4goodYeyqxvtp0TIhMA1t20CBiK4780jwnnG2LCICtrpHrlGW9D/yt5/JyDw37NVt d1iqCsBODmWQbenF8pQiIbmt5HRMpSo+Q+TO59n0hYNH3KRFVlG6IiZnBsxgWFcOmznM t8ikGxUzLiW6DC7g24GKz3Ma7eVNhb8NG4OCKBT1ciPGwc3xjcxbF6tk6i89m1FatvfQ Zp/9vHr6txuIpD/6qdiRod7Ag2DPfZm19zhwqlFpAFtkK6phA01qwbxT+3i0gqbs774/ /Rfg== X-Gm-Message-State: APjAAAUl+/aq6uS6iCKr2yLJvE5jg+tBCOD22TjxEkJNIq8A1GuOhWDu h1shir7MFitOEYpEaO0Iiso= X-Google-Smtp-Source: APXvYqyuJVhTme6dNyn9eOJj4i5TBbNgNXy/l6eJfzz62HxGRdIayLKDm6TKwRfqZYDgxo43JDDaUw== X-Received: by 2002:a05:600c:54e:: with SMTP id k14mr21459023wmc.115.1581945885771; Mon, 17 Feb 2020 05:24:45 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id i204sm601920wma.44.2020.02.17.05.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Feb 2020 05:24:44 -0800 (PST) Date: Mon, 17 Feb 2020 14:24:43 +0100 From: Michal Hocko To: Yafang Shao Cc: Roman Gushchin , Johannes Weiner , Vladimir Davydov , Andrew Morton , Chris Down , Linux MM , stable@vger.kernel.org Subject: Re: [PATCH resend] mm, memcg: reset memcg's memory.{min, low} for reclaiming itself Message-ID: <20200217132443.GM31531@dhcp22.suse.cz> References: <20200216145249.6900-1-laoar.shao@gmail.com> <20200217092459.GG31531@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon 17-02-20 21:08:12, Yafang Shao wrote: > On Mon, Feb 17, 2020 at 5:25 PM Michal Hocko wrote: > > > > On Sun 16-02-20 09:52:49, Yafang Shao wrote: > > > memory.{emin, elow} are set in mem_cgroup_protected(), and the values of > > > them won't be changed until next recalculation in this function. After > > > either or both of them are set, the next reclaimer to relcaim this memcg > > > may be a different reclaimer, e.g. this memcg is also the root memcg of > > > the new reclaimer, and then in mem_cgroup_protection() in get_scan_count() > > > the old values of them will be used to calculate scan count, that is not > > > proper. We should reset them to zero in this case. > > > > > > Here's an example of this issue. > > > > > > root_mem_cgroup > > > / > > > A memory.max=1024M memory.min=512M memory.current=800M > > > > > > Once kswapd is waked up, it will try to scan all MEMCGs, including > > > this A, and it will assign memory.emin of A with 512M. > > > After that, A may reach its hard limit(memory.max), and then it will > > > do memcg reclaim. Because A is the root of this reclaimer, so it will > > > not calculate its memory.emin. So the memory.emin is the old value > > > 512M, and then this old value will be used in > > > mem_cgroup_protection() in get_scan_count() to get the scan count. > > > That is not proper. > > > > Please document user visible effects of this patch. What does it mean > > that this is not proper behavior? > > In the memcg reclaim, if the target memcg is the root of the reclaimer, > the reclaimer should scan this memcg's all page cache pages in the LRU, > but now as the old memcg.{emin, elow} value are still there, it will get > a wrong protection value, > and the reclaimer can't reclaim the page cache pages protected by this > wrong protection. Could you be more specific please. Your example above says that emin is not going to be recalculated and stays at 512M even for a potential max limit reclaim. The min limit is still 512M so why is this value wrong? > > What happens if we have concurrent > > reclaimers at different levels of the hierarchy how that would affect > > the resulting protection? > > > > Well, I thought the synchronization mechanisms have already existed ? > Otherwise there must be concurrent issue in the original code of > setting the memcg.{emin, elow} as well. > (Because memcg->memory.{emin, elow} are also set at the end of the > function mem_cgroup_protected()) This function is documented to be racy and I believe this is OK because it doesn't really have to be precise and concurrent updates are not going to change values much. But does the same apply to reseting the effective values? Maybe yes. Make sure to document this in the changelog please. -- Michal Hocko SUSE Labs