[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160629072524.GA18523@bbox>
Date: Wed, 29 Jun 2016 16:25:24 +0900
From: Minchan Kim <minchan@...nel.org>
To: Chen Feng <puck.chen@...ilicon.com>
CC: Vladimir Davydov <vdavydov@...tuozzo.com>,
<akpm@...ux-foundation.org>, <hannes@...xchg.org>,
<mhocko@...e.com>, <vbabka@...e.cz>, <mgorman@...hsingularity.net>,
<riel@...hat.com>, <linux-mm@...ck.org>,
<linux-kernel@...r.kernel.org>, <labbott@...hat.com>,
<suzhuangluan@...ilicon.com>, <oliver.fu@...ilicon.com>,
<puck.chen@...mail.com>, <dan.zhao@...ilicon.com>,
<saberlily.xia@...ilicon.com>, <xuyiping@...ilicon.com>
Subject: Re: [PATCH] mm, vmscan: set shrinker to the left page count
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.
Powered by blists - more mailing lists