From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751474AbdFFNIG (ORCPT ); Tue, 6 Jun 2017 09:08:06 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:7755 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751305AbdFFNIE (ORCPT ); Tue, 6 Jun 2017 09:08:04 -0400 Message-ID: <5936A787.4050002@huawei.com> Date: Tue, 6 Jun 2017 21:00:55 +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> In-Reply-To: <20170130234028.GA7942@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.0A020206.5936A7A4.0117,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: e9fcba7c58ed3e22141afc7dd83bb50f Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks zhongjiang >>>>>> unsigned arithmetic results in the pressure value to be >>>>>> huge, thus resulting in a critical event being sent to >>>>>> root cgroup. Fix this by not passing the reclaimed slab >>>>>> count to vmpressure, with the assumption that vmpressure >>>>>> should show the actual pressure on LRU which is now >>>>>> diluted by adding reclaimed slab without a corresponding >>>>>> scanned value. >>>>> I can't guess justfication of your assumption from the description. >>>>> Why do we consider only LRU pages for vmpressure? Could you elaborate >>>>> a bit? >>>>> >>>> When we encountered the false events from vmpressure, thought the problem >>>> could be that slab scanned is not included in sc->nr_scanned, like it is done >>>> for reclaimed. But later thought vmpressure works only on the scanned and >>>> reclaimed from LRU. I can explain what I understand, let me know if this is >>>> incorrect. >>>> vmpressure is an index which tells the pressure on LRU, and thus an >>>> indicator of thrashing. In shrink_node when we come out of the inner do-while >>>> loop after shrinking the lruvec, the scanned and reclaimed corresponds to the >>>> pressure felt on the LRUs which in turn indicates the pressure on VM. The >>>> moment we add the slab reclaimed pages to the reclaimed, we dilute the >>>> actual pressure felt on LRUs. When slab scanned/reclaimed is not included >>>> in the vmpressure, the values will indicate the actual pressure and if there >>>> were a lot of slab reclaimed pages it will result in lesser pressure >>>> on LRUs in the next run which will again be indicated by vmpressure. i.e. the >>> I think there is no intention to exclude slab by design of vmpressure. >>> Beause slab is memory consumption so freeing of slab pages really helps >>> the memory pressure. Also, there might be slab-intensive workload rather >>> than LRU. It would be great if vmpressure works well with that case. >>> But the problem with involving slab for vmpressure is it's not fair with >>> LRU pages. LRU pages are 1:1 cost model for scan:free but slab shriking >>> depends the each slab's object population. It means it's impossible to >>> get stable cost model with current slab shrinkg model, unfortunately. >>> So I don't obejct this patch although I want to see slab shrink model's >>> change which is heavy-handed work. >>> >> Looking at the code, the slab reclaimed pages started getting passed to >> vmpressure after the commit ("mm: vmscan: invoke slab shrinkers from >> shrink_zone()"). >> But as you said, this may be helpful for slab intensive workloads. But in its >> current form I think it results in incorrect vmpressure reporting because of not >> accounting the slab scanned pages. Resending the patch with a modified >> commit msg >> since the underflow issue is fixed separately. Thanks Minchan. > Make sense. > > Thanks, Vinayak! > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org > > . >