Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9230989imu; Wed, 5 Dec 2018 01:00:19 -0800 (PST) X-Google-Smtp-Source: AFSGD/VLTddGjfilSmeyeJ6ayf2dgNvM2a9TAuJBCbfdPHAHp8abkZJL2vB/qQydjnDX2KAZqI6n X-Received: by 2002:a17:902:14e:: with SMTP id 72mr23496404plb.287.1544000419618; Wed, 05 Dec 2018 01:00:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544000419; cv=none; d=google.com; s=arc-20160816; b=vMrPsyJsi8bBzzKk6dAFfswYi8wOZDZBI+de2xu9MBVYMWRv7JBMu3AgWz8lg0LB2L Cdd+s9cwKzXRZXwg07exGycGJT1pAC+OQq1aji1JP5m/SqfGuqSThbRY/EvdjHSgXBWp 8A/ZJcMXN3EPkIuEOn8OmRDgJ9/cLP7s5bVqeXOI3Fx/M9GQpyiS0mLxgeVPjlwuW4YE lJjBtunkBR36+Oa+S25+3Ujb4/7aV+aSDDt2tfXE2FJQDCTvtlLm3knSbzcMaW7kwPBv 1Zpjkd/x+luvtESJOoN+Qt7rYKltzCii/9Zwj2yE677mYlcno87A2ZIsaeoq7PcHVcMm uzfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject:reply-to; bh=1KjuXzLMvOvTvPlryFl9YjWLkK7LhcoOQKy2Ef0LoeI=; b=c+kp5+U8Z+DLPeV4gSOEv1mppiFcVFNIz95FZfxIFMize8C0ZjndWFuedQHY55Ct8m uTY++FtUSAVT0pQMm3aB2U1iS4kSIvyY9YwGVCvK7P0cUJ1M54cIww+3Nah4/fva+7tH zW4RpXHoBhyyJwqa0rBopBLFHp7+hu7VS6N9i465HJdWlNCd5avPmFMt+g/GNbKbqNJv bd63RXOKkiKOZMhSq2jf36rI/oKxlZqnh39PrxtVehE/1UUAy2/Lhu5R7Xcxn+k4nIcz j+rJvwVd1dhCNQDCB0cLxIX2RMfWc+wt/NS/ykNuhkUQtnRgtq/b2HGUC+466jpkwm5e r7Jg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k7si18042215pgm.462.2018.12.05.01.00.04; Wed, 05 Dec 2018 01:00:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727225AbeLEI7a (ORCPT + 99 others); Wed, 5 Dec 2018 03:59:30 -0500 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:40133 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726102AbeLEI7a (ORCPT ); Wed, 5 Dec 2018 03:59:30 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07486;MF=xlpang@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0TEv2g.D_1544000312; Received: from xunleideMacBook-Pro.local(mailfrom:xlpang@linux.alibaba.com fp:SMTPD_---0TEv2g.D_1544000312) by smtp.aliyun-inc.com(127.0.0.1); Wed, 05 Dec 2018 16:58:32 +0800 Reply-To: xlpang@linux.alibaba.com Subject: Re: [PATCH 1/3] mm/memcg: Fix min/low usage in propagate_protected_usage() To: Roman Gushchin Cc: Michal Hocko , Johannes Weiner , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" References: <20181203080119.18989-1-xlpang@linux.alibaba.com> <20181203180008.GB31090@castle.DHCP.thefacebook.com> From: Xunlei Pang Message-ID: <03652447-d9ba-45ea-3365-46a4caf96748@linux.alibaba.com> Date: Wed, 5 Dec 2018 16:58:31 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <20181203180008.GB31090@castle.DHCP.thefacebook.com> Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roman, On 2018/12/4 AM 2:00, Roman Gushchin wrote: > On Mon, Dec 03, 2018 at 04:01:17PM +0800, Xunlei Pang wrote: >> When usage exceeds min, min usage should be min other than 0. >> Apply the same for low. >> >> Signed-off-by: Xunlei Pang >> --- >> mm/page_counter.c | 12 ++---------- >> 1 file changed, 2 insertions(+), 10 deletions(-) >> >> diff --git a/mm/page_counter.c b/mm/page_counter.c >> index de31470655f6..75d53f15f040 100644 >> --- a/mm/page_counter.c >> +++ b/mm/page_counter.c >> @@ -23,11 +23,7 @@ static void propagate_protected_usage(struct page_counter *c, >> return; >> >> if (c->min || atomic_long_read(&c->min_usage)) { >> - if (usage <= c->min) >> - protected = usage; >> - else >> - protected = 0; >> - >> + protected = min(usage, c->min); > > This change makes sense in the combination with the patch 3, but not as a > standlone "fix". It's not a bug, it's a required thing unless you start scanning > proportionally to memory.low/min excess. > > Please, reflect this in the commit message. Or, even better, merge it into > the patch 3. The more I looked the more I think it's a bug, but anyway I'm fine with merging it into patch 3 :-) > > Also, please, make sure that cgroup kselftests are passing after your changes. Sure, will do and send v2. Thanks for your inputs.