[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170203145947.GD19325@dhcp22.suse.cz>
Date: Fri, 3 Feb 2017 15:59:48 +0100
From: Michal Hocko <mhocko@...nel.org>
To: vinayak menon <vinayakm.list@...il.com>
Cc: Vinayak Menon <vinmenon@...eaurora.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
mgorman@...hsingularity.net, vbabka@...e.cz,
Rik van Riel <riel@...hat.com>, vdavydov.dev@...il.com,
anton.vorontsov@...aro.org, Minchan Kim <minchan@...nel.org>,
shashim@...eaurora.org, "linux-mm@...ck.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 Fri 03-02-17 10:56:42, vinayak menon wrote:
> On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko <mhocko@...nel.org> wrote:
> >
> > Why would you like to chose and kill a task when the slab reclaim can
> > still make sufficient progres? Are you sure that the slab contribution
> > to the stats makes all the above happening?
> >
> I agree that a task need not be killed if sufficient progress is made
> in reclaiming
> memory say from slab. But here it looks like we have an impact because of just
> increasing the reclaimed without touching the scanned. It could be because of
> disimilar costs or not adding adding cost. I agree that vmpressure is
> only a reasonable
> estimate which does not already include few other costs, but I am not
> sure whether it is ok
> to add another element which further increases that disparity.
> We noticed this problem when moving from 3.18 to 4.4 kernel version. With the
> same workload, the vmpressure events differ between 3.18 and 4.4 causing the
> above mentioned problem. And with this patch on 4.4 we get the same results
> as in 3,18. So the slab contribution to stats is making a difference.
Please document that in the changelog along with description of the
workload that is affected. Ideally also add some data from /proc/vmstat
so that we can see the reclaim activity.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists