[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170510072205.GB31466@dhcp22.suse.cz>
Date: Wed, 10 May 2017 09:22:06 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Minchan Kim <minchan@...nel.org>
Cc: Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...hsingularity.net>, kernel-team@....com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] vmscan: scan pages until it founds eligible pages
On Wed 10-05-17 16:03:11, Minchan Kim wrote:
> On Wed, May 10, 2017 at 08:13:12AM +0200, Michal Hocko wrote:
> > On Wed 10-05-17 10:46:54, Minchan Kim wrote:
> > > On Wed, May 03, 2017 at 08:00:44AM +0200, Michal Hocko wrote:
[...]
> > > > + scan++;
> > > > switch (__isolate_lru_page(page, mode)) {
> > > > case 0:
> > > > nr_pages = hpage_nr_pages(page);
> > >
> > > Confirmed.
> >
> > Hmm. I can clearly see how we could skip over too many pages and hit
> > small reclaim priorities too quickly but I am still scratching my head
> > about how we could hit the OOM killer as a result. The amount of pages
> > on the active anonymous list suggests that we are not able to rotate
> > pages quickly enough. I have to keep thinking about that.
>
> I explained it but seems to be not enouggh. Let me try again.
>
> The problem is that get_scan_count determines nr_to_scan with
> eligible zones.
>
> size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx);
> size = size >> sc->priority;
Ohh, right. Who has done that ;) Now it is much more clear. We simply
reclaimed all the pages on the inactive LRU list and only very slowly
progress over active list and hit the OOM before we can actually reach
anything. I completely forgot about the scan window not being the full
LRU list.
Thanks for bearing with me!
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists