[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121214161345.GA18780@dhcp22.suse.cz>
Date: Fri, 14 Dec 2012 17:13:45 +0100
From: Michal Hocko <mhocko@...e.cz>
To: Rik van Riel <riel@...hat.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
Satoru Moriya <satoru.moriya@....com>,
Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
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 Fri 14-12-12 10:43:55, Rik van Riel wrote:
> On 12/14/2012 03:37 AM, Michal Hocko wrote:
>
> >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?
>
> swappiness==0 will swap in emergencies, specifically when we have
> almost no page cache left, we will still swap things out:
>
> if (global_reclaim(sc)) {
> free = zone_page_state(zone, NR_FREE_PAGES);
> if (unlikely(file + free <= high_wmark_pages(zone))) {
> /*
> * If we have very few page cache pages, force-scan
> * anon pages.
> */
> fraction[0] = 1;
> fraction[1] = 0;
> denominator = 1;
> goto out;
>
> This makes sense, because people who set swappiness==0 but
> do have swap space available would probably prefer some
> emergency swapping over an OOM kill.
Yes, but this is the global reclaim path. I was arguing about
swappiness==0 & memcg. As this patch doesn't make a big difference for
the global case (as both the changelog and you mentioned) then we should
focus on whether this is desirable change for the memcg path. I think it
makes sense to keep "no swapping at all for memcg semantic" as we have
it currently.
--
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