[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121214083738.GA6898@dhcp22.suse.cz>
Date: Fri, 14 Dec 2012 09:37:38 +0100
From: Michal Hocko <mhocko@...e.cz>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Satoru Moriya <satoru.moriya@....com>,
Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Hugh Dickins <hughd@...gle.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2/8] mm: vmscan: disregard swappiness shortly before
going OOM
On Thu 13-12-12 23:50:30, Johannes Weiner wrote:
> On Thu, Dec 13, 2012 at 10:25:43PM +0000, Satoru Moriya wrote:
> >
> > On 12/13/2012 11:05 AM, Michal Hocko wrote:> On Thu 13-12-12 16:29:59, Michal Hocko wrote:
> > >> On Thu 13-12-12 10:34:20, Mel Gorman wrote:
> > >>> On Wed, Dec 12, 2012 at 04:43:34PM -0500, Johannes Weiner wrote:
> > >>>> When a reclaim scanner is doing its final scan before giving up and
> > >>>> there is swap space available, pay no attention to swappiness
> > >>>> preference anymore. Just swap.
> > >>>>
> > >>>> Note that this change won't make too big of a difference for
> > >>>> general
> > >>>> reclaim: anonymous pages are already force-scanned when there is
> > >>>> only very little file cache left, and there very likely isn't when
> > >>>> the reclaimer enters this final cycle.
> > >>>>
> > >>>> Signed-off-by: Johannes Weiner <hannes@...xchg.org>
> > >>>
> > >>> Ok, I see the motivation for your patch but is the block inside
> > >>> still wrong for what you want? After your patch the block looks like
> > >>> this
> > >>>
> > >>> if (sc->priority || noswap) {
> > >>> scan >>= sc->priority;
> > >>> if (!scan && force_scan)
> > >>> scan = SWAP_CLUSTER_MAX;
> > >>> scan = div64_u64(scan * fraction[file], denominator);
> > >>> }
> > >>>
> > >>> if sc->priority == 0 and swappiness==0 then you enter this block but
> > >>> fraction[0] for anonymous pages will also be 0 and because of the
> > >>> ordering of statements there, scan will be
> > >>>
> > >>> scan = scan * 0 / denominator
> > >>>
> > >>> so you are still not reclaiming anonymous pages in the swappiness=0
> > >>> case. What did I miss?
> > >>
> > >> Yes, now that you have mentioned that I realized that it really
> > >> doesn't make any sense. fraction[0] is _always_ 0 for swappiness==0.
> > >> So we just made a bigger pressure on file LRUs. So this sounds like a
> > >> misuse of the swappiness. This all has been introduced with fe35004f
> > >> (mm: avoid swapping out with swappiness==0).
> > >>
> > >> I think that removing swappiness check make sense but I am not sure
> > >> it does what the changelog says. It should have said that checking
> > >> swappiness doesn't make any sense for small LRUs.
> > >
> > > Bahh, wait a moment. Now I remember why the check made sense
> > > especially for memcg.
> > > It made "don't swap _at all_ for swappiness==0" for real - you are
> > > even willing to sacrifice OOM. Maybe this is OK for the global case
> > > because noswap would safe you here (assuming that there is no swap if
> > > somebody doesn't want to swap at all and swappiness doesn't play such
> > > a big role) but for memcg you really might want to prevent from
> > > swapping - not everybody has memcg swap extension enabled and swappiness is handy then.
> > > So I am not sure this is actually what we want. Need to think about it.
> >
> > I introduced swappiness check here with fe35004f because, in some
> > cases, we prefer OOM to swap out pages to detect problems as soon
> > as possible. Basically, we design the system not to swap out and
> > so if it causes swapping, something goes wrong.
>
> I might be missing something terribly obvious, but... why do you add
> swap space to the system in the first place? Or in case of cgroups,
> why not set the memsw limit equal to the memory limit?
I can answer the later. Because memsw comes with its price and
swappiness is much cheaper. On the other hand it makes sense that
swappiness==0 doesn't swap at all. Or do you think we should get back to
_almost_ doesn't swap at all?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists