linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Satoru Moriya <satoru.moriya@hds.com>
Cc: Michal Hocko <mhocko@suse.cz>, Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [patch 2/8] mm: vmscan: disregard swappiness shortly before going OOM
Date: Thu, 13 Dec 2012 23:50:30 -0500	[thread overview]
Message-ID: <20121214045030.GE6317@cmpxchg.org> (raw)
In-Reply-To: <8631DC5930FA9E468F04F3FD3A5D007214AD2FA2@USINDEM103.corp.hds.com>

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@cmpxchg.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?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-12-14  4:51 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-12 21:43 [patch 0/8] page reclaim bits Johannes Weiner
2012-12-12 21:43 ` [patch 1/8] mm: memcg: only evict file pages when we have plenty Johannes Weiner
2012-12-12 21:53   ` Rik van Riel
2012-12-12 22:28     ` Johannes Weiner
2012-12-13 10:07       ` Mel Gorman
2012-12-13 14:44         ` Mel Gorman
2012-12-13 14:55       ` Michal Hocko
2012-12-16  1:21         ` Simon Jeons
2012-12-17 15:54           ` Michal Hocko
2012-12-19  5:21             ` Simon Jeons
2012-12-19  9:20               ` Mel Gorman
2012-12-13  5:36     ` Simon Jeons
2012-12-13  5:34   ` Simon Jeons
2012-12-12 21:43 ` [patch 2/8] mm: vmscan: disregard swappiness shortly before going OOM Johannes Weiner
2012-12-12 22:01   ` Rik van Riel
2012-12-13  5:56   ` Simon Jeons
2012-12-13 10:34   ` Mel Gorman
2012-12-13 15:29     ` Michal Hocko
2012-12-13 16:05       ` Michal Hocko
2012-12-13 22:25         ` Satoru Moriya
2012-12-14  4:50           ` Johannes Weiner [this message]
2012-12-14  8:37             ` Michal Hocko
2012-12-14 15:43               ` Rik van Riel
2012-12-14 16:13                 ` Michal Hocko
2012-12-15  0:18                   ` Johannes Weiner
2012-12-17 16:37                     ` Michal Hocko
2012-12-17 17:54                       ` Johannes Weiner
2012-12-17 19:58                         ` Michal Hocko
2012-12-14 20:17                 ` Satoru Moriya
2012-12-14 19:44               ` Satoru Moriya
2012-12-13 19:05     ` Johannes Weiner
2012-12-13 19:47       ` Mel Gorman
2012-12-12 21:43 ` [patch 3/8] mm: vmscan: save work scanning (almost) empty LRU lists Johannes Weiner
2012-12-12 22:02   ` Rik van Riel
2012-12-13 10:41   ` Mel Gorman
2012-12-13 19:33     ` Johannes Weiner
2012-12-13 15:43   ` Michal Hocko
2012-12-13 19:38     ` Johannes Weiner
2012-12-14  8:46       ` Michal Hocko
2012-12-12 21:43 ` [patch 4/8] mm: vmscan: clarify LRU balancing close to OOM Johannes Weiner
2012-12-12 22:03   ` Rik van Riel
2012-12-13 10:46   ` Mel Gorman
2012-12-12 21:43 ` [patch 5/8] mm: vmscan: improve comment on low-page cache handling Johannes Weiner
2012-12-12 22:04   ` Rik van Riel
2012-12-13 10:47   ` Mel Gorman
2012-12-13 16:07   ` Michal Hocko
2012-12-12 21:43 ` [patch 6/8] mm: vmscan: clean up get_scan_count() Johannes Weiner
2012-12-12 22:06   ` Rik van Riel
2012-12-13 11:07   ` Mel Gorman
2012-12-13 16:18   ` Michal Hocko
2012-12-12 21:43 ` [patch 7/8] mm: vmscan: compaction works against zones, not lruvecs Johannes Weiner
2012-12-12 22:31   ` Rik van Riel
2012-12-13 11:12   ` Mel Gorman
2012-12-13 16:48   ` Michal Hocko
2012-12-12 21:43 ` [patch 8/8] mm: reduce rmap overhead for ex-KSM page copies created on swap faults Johannes Weiner
2012-12-12 22:34   ` Rik van Riel
2012-12-12 21:50 ` [patch 0/8] page reclaim bits Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121214045030.GE6317@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=riel@redhat.com \
    --cc=satoru.moriya@hds.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox