From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752689AbcF2HZA (ORCPT ); Wed, 29 Jun 2016 03:25:00 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:42619 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751173AbcF2HY6 convert rfc822-to-8bit (ORCPT ); Wed, 29 Jun 2016 03:24:58 -0400 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.150 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Wed, 29 Jun 2016 16:25:24 +0900 From: Minchan Kim To: Chen Feng CC: Vladimir Davydov , , , , , , , , , , , , , , , Subject: Re: [PATCH] mm, vmscan: set shrinker to the left page count Message-ID: <20160629072524.GA18523@bbox> References: <1467025335-6748-1-git-send-email-puck.chen@hisilicon.com> <20160627165723.GW21652@esperanza> <57725364.60307@hisilicon.com> MIME-Version: 1.0 In-Reply-To: <57725364.60307@hisilicon.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB01/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/29 16:24:55, Serialize by Router on LGEKRMHUB01/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/29 16:24:55 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 28, 2016 at 06:37:24PM +0800, Chen Feng wrote: > 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. So, the problem is LMK is too agressive. If it's really problem, you could fix LMK to consider reclaimable slab as well as file pages. Thanks.