[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170203061737.GA32372@bbox>
Date: Fri, 3 Feb 2017 15:17:37 +0900
From: Minchan Kim <minchan@...nel.org>
To: Michal Hocko <mhocko@...nel.org>
Cc: Vinayak Menon <vinmenon@...eaurora.org>, akpm@...ux-foundation.org,
hannes@...xchg.org, mgorman@...hsingularity.net, vbabka@...e.cz,
riel@...hat.com, vdavydov.dev@...il.com,
anton.vorontsov@...aro.org, shashim@...eaurora.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to
vmpressure
On Thu, Feb 02, 2017 at 11:44:22AM +0100, Michal Hocko wrote:
> On Tue 31-01-17 14:32:08, Vinayak Menon wrote:
> > During global reclaim, the nr_reclaimed passed to vmpressure
> > includes the pages reclaimed from slab. But the corresponding
> > scanned slab pages is not passed. This can cause total reclaimed
> > pages to be greater than scanned, causing an unsigned underflow
> > in vmpressure resulting in a critical event being sent to root
> > cgroup. So do not consider reclaimed slab pages for vmpressure
> > calculation. The reclaimed pages from slab can be excluded because
> > the freeing of a page by slab shrinking depends on each slab's
> > object population, making the cost model (i.e. scan:free) different
> > from that of LRU.
>
> This might be true but what happens if the slab reclaim contributes
> significantly to the overal reclaim? This would be quite rare but not
> impossible.
Of course, it is better for vmpressure to cover slab but it's not
easy without page-based shrinking model, I think. It wold make
vmpressure higher easily due to low reclaim efficiency compared to
LRU pages. Yeah, vmpressure is not a perfect but no need to add
more noises, either. It's regression since 6b4f7799c6a5 so I think
this patch should go first and if someone want to cover slab really,
he should spend a time to work it well. It's too much that Vinayak
shuld make a effort for that.
Powered by blists - more mailing lists