From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751536AbdFGDIA (ORCPT ); Tue, 6 Jun 2017 23:08:00 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:6876 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751474AbdFGDH7 (ORCPT ); Tue, 6 Jun 2017 23:07:59 -0400 Message-ID: <59376DEA.2080900@huawei.com> Date: Wed, 7 Jun 2017 11:07:22 +0800 From: zhong jiang User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Minchan Kim CC: vinayak menon , Vinayak Menon , Andrew Morton , Johannes Weiner , , , , Rik van Riel , , , Shiraz Hashim , "linux-mm@kvack.org" , Subject: Re: [PATCH] mm: vmscan: do not pass reclaimed slab to vmpressure References: <1485344318-6418-1-git-send-email-vinmenon@codeaurora.org> <20170125232713.GB20811@bbox> <20170126141836.GA3584@bbox> <20170130234028.GA7942@bbox> <5936A787.4050002@huawei.com> <20170607025324.GB18007@bbox> In-Reply-To: <20170607025324.GB18007@bbox> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.68] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59376E03.0061,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3b4b636758a7c81a067114ba50a140c2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017/6/7 10:53, Minchan Kim wrote: > Hi, > > On Tue, Jun 06, 2017 at 09:00:55PM +0800, zhong jiang wrote: >> On 2017/1/31 7:40, Minchan Kim wrote: >>> Hi Vinayak, >>> Sorry for late response. It was Lunar New Year holidays. >>> >>> On Fri, Jan 27, 2017 at 01:43:23PM +0530, vinayak menon wrote: >>>>> Thanks for the explain. However, such case can happen with THP page >>>>> as well as slab. In case of THP page, nr_scanned is 1 but nr_reclaimed >>>>> could be 512 so I think vmpressure should have a logic to prevent undeflow >>>>> regardless of slab shrinking. >>>>> >>>> I see. Going to send a vmpressure fix. But, wouldn't the THP case >>>> result in incorrect >>>> vmpressure reporting even if we fix the vmpressure underflow problem ? >>> If a THP page is reclaimed, it reports lower pressure due to bigger >>> reclaim ratio(ie, reclaimed/scanned) compared to normal pages but >>> it's not a problem, is it? Because VM reclaimed more memory than >>> expected so memory pressure isn't severe now. >> Hi, Minchan >> >> THP lru page is reclaimed, reclaim ratio bigger make sense. but I read the code, I found >> THP is split to normal pages and loop again. reclaimed pages should not be bigger >> than nr_scan. because of each loop will increase nr_scan counter. >> >> It is likely I miss something. you can point out the point please. > You are absolutely right. > > I got confused by nr_scanned from isolate_lru_pages and sc->nr_scanned > from shrink_page_list. > > Thanks. > > > . > Hi, Minchan I will send the revert patch shortly. how do you think? Thanks zhongjiang