From: Vlastimil Babka <vbabka@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>
Cc: linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH] mm: fix negative nr_isolated counts
Date: Thu, 12 Feb 2015 09:18:14 +0100 [thread overview]
Message-ID: <54DC61C6.10502@suse.cz> (raw)
In-Reply-To: <20150211130905.4b0d1809b0689ffd6e83d851@linux-foundation.org>
On 02/11/2015 10:09 PM, Andrew Morton wrote:
> On Tue, 10 Feb 2015 23:06:09 -0800 (PST) Hugh Dickins <hughd@google.com> wrote:
>
>> The vmstat interfaces are good at hiding negative counts (at least
>> when CONFIG_SMP); but if you peer behind the curtain, you find that
>> nr_isolated_anon and nr_isolated_file soon go negative, and grow ever
>> more negative: so they can absorb larger and larger numbers of isolated
>> pages, yet still appear to be zero.
>>
>> I'm happy to avoid a congestion_wait() when too_many_isolated() myself;
>> but I guess it's there for a good reason, in which case we ought to get
>> too_many_isolated() working again.
>>
>> The imbalance comes from isolate_migratepages()'s ISOLATE_ABORT case:
>> putback_movable_pages() decrements the NR_ISOLATED counts, but we forgot
>> to call acct_isolated() to increment them.
>
> So if I'm understanding this correctly, shrink_inactive_list()'s call
> to congestion_wait() basically never happens?
I think so, the more the counters go negative, the less chance of
congestion_wait() to happen from there.
> If so I'm pretty reluctant to merge this up until it has had plenty of
> careful testing - there's a decent chance that it will make the kernel
> behave worse.
You mean "worse" by letting shrink_inactive_list() call
congestion_wait() again, as it used to before 3.18, since 2009 it seems?
Maybe it's not needed anymore, but it IMHO shouldn't get disabled by
accident, but properly evaluated and removed. Hugh's patch just fixes
the accidental disable.
>> Fixes: edc2ca612496 ("mm, compaction: move pageblock checks up from isolate_migratepages_range()")
>> Signed-off-by: Hugh Dickins <hughd@google.com>
>> Cc: stable@vger.kernel.org # v3.18+
>
> And why -stable? What user-visible problem is the bug causing?
>
Commit 35cd78156c "vmscan: throttle direct reclaim when too many pages
are isolated already" by Rik seems to have introduced this
congestion_wait() based on too_many_isolated(). The bug it was fixing:
"When way too many processes go into direct reclaim, it is possible
for all of the pages to be taken off the LRU. One result of this is that
the next process in the page reclaim code thinks there are no
reclaimable pages left and triggers an out of memory kill."
So either this is now prevented by something else and
too_many_isolated() could go away, or we should restore its
functionality. Any idea, Rik?
--
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>
next prev parent reply other threads:[~2015-02-12 8:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 7:06 [PATCH] mm: fix negative nr_isolated counts Hugh Dickins
2015-02-11 9:58 ` Vlastimil Babka
2015-02-12 7:10 ` Joonsoo Kim
2015-02-11 21:09 ` Andrew Morton
2015-02-12 8:18 ` Vlastimil Babka [this message]
2015-02-12 15:12 ` Rik van Riel
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=54DC61C6.10502@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.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;
as well as URLs for NNTP newsgroup(s).