From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753018AbcF1KlP (ORCPT ); Tue, 28 Jun 2016 06:41:15 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:18361 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752991AbcF1KlK (ORCPT ); Tue, 28 Jun 2016 06:41:10 -0400 Subject: Re: [PATCH] mm, vmscan: set shrinker to the left page count To: Vladimir Davydov References: <1467025335-6748-1-git-send-email-puck.chen@hisilicon.com> <20160627165723.GW21652@esperanza> CC: , , , , , , , , , , , , , , From: Chen Feng Message-ID: <57725364.60307@hisilicon.com> Date: Tue, 28 Jun 2016 18:37:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160627165723.GW21652@esperanza> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.142.193.64] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.57725374.0184,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7982658883117355d5018595c0cb0239 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for you reply. On 2016/6/28 0:57, Vladimir Davydov wrote: > On Mon, Jun 27, 2016 at 07:02:15PM +0800, Chen Feng wrote: >> In my platform, there can be cache a lot of memory in >> ion page pool. When shrink memory the nr_to_scan to ion >> is always to little. >> to_scan: 395 ion_pool_cached: 27305 > > That's OK. We want to shrink slabs gradually, not all at once. > OK， But my question there are a lot of memory waiting for free. But the to_scan is too little. So, the lowmemorykill may kill the wrong process. >> >> Currently, the shrinker nr_deferred is set to total_scan. >> But it's not the real left of the shrinker. > > And it shouldn't. The idea behind nr_deferred is following. A shrinker > may return SHRINK_STOP if the current allocation context doesn't allow > to reclaim its objects (e.g. reclaiming inodes under GFP_NOFS is > deadlock prone). In this case we can't call the shrinker right now, but > if we just forget about the batch we are supposed to reclaim at the > current iteration, we can wind up having too many of these objects so > that they start to exert unfairly high pressure on user memory. So we > add the amount that we wanted to scan but couldn't to nr_deferred, so > that we can catch up when we get to shrink_slab() with a proper context. > I am confused with your comments. If the shrinker return STOP this time. It also can return STOP next time. Is there any other effects about this change？ Any feedback is appreciated. Thanks. >> Change it to >> the freeable - freed. >> >> Signed-off-by: Chen Feng >> --- >> mm/vmscan.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index c4a2f45..1ce3fc4 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -357,8 +357,8 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, >> * manner that handles concurrent updates. If we exhausted the >> * scan, there is no need to do an update. >> */ >> - if (total_scan > 0) >> - new_nr = atomic_long_add_return(total_scan, >> + if (freeable - freed > 0) >> + new_nr = atomic_long_add_return(freeable - freed, >> &shrinker->nr_deferred[nid]); >> else >> new_nr = atomic_long_read(&shrinker->nr_deferred[nid]); > > -- > 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 > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f198.google.com (mail-io0-f198.google.com [209.85.223.198]) by kanga.kvack.org (Postfix) with ESMTP id DE36B6B025F for ; Tue, 28 Jun 2016 06:38:29 -0400 (EDT) Received: by mail-io0-f198.google.com with SMTP id k78so28213276ioi.2 for ; Tue, 28 Jun 2016 03:38:29 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com. [119.145.14.66]) by mx.google.com with ESMTPS id l129si9432747oif.118.2016.06.28.03.38.27 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 28 Jun 2016 03:38:29 -0700 (PDT) Subject: Re: [PATCH] mm, vmscan: set shrinker to the left page count References: <1467025335-6748-1-git-send-email-puck.chen@hisilicon.com> <20160627165723.GW21652@esperanza> From: Chen Feng Message-ID: <57725364.60307@hisilicon.com> Date: Tue, 28 Jun 2016 18:37:24 +0800 MIME-Version: 1.0 In-Reply-To: <20160627165723.GW21652@esperanza> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Vladimir Davydov Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, mhocko@suse.com, vbabka@suse.cz, mgorman@techsingularity.net, riel@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, labbott@redhat.com, suzhuangluan@hisilicon.com, oliver.fu@hisilicon.com, puck.chen@foxmail.com, dan.zhao@hisilicon.com, saberlily.xia@hisilicon.com, xuyiping@hisilicon.com Thanks for you reply. On 2016/6/28 0:57, Vladimir Davydov wrote: > On Mon, Jun 27, 2016 at 07:02:15PM +0800, Chen Feng wrote: >> In my platform, there can be cache a lot of memory in >> ion page pool. When shrink memory the nr_to_scan to ion >> is always to little. >> to_scan: 395 ion_pool_cached: 27305 > > That's OK. We want to shrink slabs gradually, not all at once. > OKi 1/4 ? But my question there are a lot of memory waiting for free. But the to_scan is too little. So, the lowmemorykill may kill the wrong process. >> >> Currently, the shrinker nr_deferred is set to total_scan. >> But it's not the real left of the shrinker. > > And it shouldn't. The idea behind nr_deferred is following. A shrinker > may return SHRINK_STOP if the current allocation context doesn't allow > to reclaim its objects (e.g. reclaiming inodes under GFP_NOFS is > deadlock prone). In this case we can't call the shrinker right now, but > if we just forget about the batch we are supposed to reclaim at the > current iteration, we can wind up having too many of these objects so > that they start to exert unfairly high pressure on user memory. So we > add the amount that we wanted to scan but couldn't to nr_deferred, so > that we can catch up when we get to shrink_slab() with a proper context. > I am confused with your comments. If the shrinker return STOP this time. It also can return STOP next time. Is there any other effects about this changei 1/4 ? Any feedback is appreciated. Thanks. >> Change it to >> the freeable - freed. >> >> Signed-off-by: Chen Feng >> --- >> mm/vmscan.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index c4a2f45..1ce3fc4 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -357,8 +357,8 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, >> * manner that handles concurrent updates. If we exhausted the >> * scan, there is no need to do an update. >> */ >> - if (total_scan > 0) >> - new_nr = atomic_long_add_return(total_scan, >> + if (freeable - freed > 0) >> + new_nr = atomic_long_add_return(freeable - freed, >> &shrinker->nr_deferred[nid]); >> else >> new_nr = atomic_long_read(&shrinker->nr_deferred[nid]); > > -- > 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 > > -- 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