From: Oleg Nesterov <oleg@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: zone_reclaimable() leads to livelock in __alloc_pages_slowpath()
Date: Wed, 1 Jun 2016 01:56:26 +0200 [thread overview]
Message-ID: <20160531235626.GA24319@redhat.com> (raw)
In-Reply-To: <20160531125253.GK26128@dhcp22.suse.cz>
On 05/31, Michal Hocko wrote:
>
> On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> >
> > This single change in get_scan_count() under for_each_evictable_lru() loop
> >
> > - size = lruvec_lru_size(lruvec, lru);
> > + size = zone_page_state_snapshot(lruvec_zone(lruvec), NR_LRU_BASE + lru);
> >
> > fixes the problem too.
> >
> > Without this change shrink*() continues to scan the LRU_ACTIVE_FILE list
> > while it is empty. LRU_INACTIVE_FILE is not empty (just a few pages) but
> > we do not even try to scan it, lruvec_lru_size() returns zero.
>
> OK, you seem to be really seeing a different issue than me.
quite possibly, but
> My debugging
> patch was showing when nothing was really isolated from the LRU lists
> (both for shrink_{in}active_list.
in my debugging session too. LRU_ACTIVE_FILE was empty, so there is nothing to
isolate even if shrink_active_list() is (wrongly called) with nr_to_scan != 0.
LRU_INACTIVE_FILE is not empty but it is not scanned because nr_to_scan == 0.
But I am afraid I misunderstood you, and you meant something else.
> > Then later we recheck zone_reclaimable() and it notices the INACTIVE_FILE
> > counter because it uses the _snapshot variant, this leads to livelock.
> >
> > I guess this doesn't really matter, but in my particular case these
> > ACTIVE/INACTIVE counters were screwed by the recent putback_inactive_pages()
> > logic. The pages we "leak" in INACTIVE list were recently moved from ACTIVE
> > to INACTIVE list, and this updated only the per-cpu ->vm_stat_diff[] counters,
> > so the "non snapshot" lruvec_lru_size() in get_scan_count() sees the "old"
> > numbers.
>
> Hmm. I am not really sure we can use the _snapshot version in lruvec_lru_size.
Yes, yes, I understand,
> But I am thinking whether we should simply revert 0db2cb8da89d ("mm,
> vmscan: make zone_reclaimable_pages more precise") in 4.6 stable tree.
> Does that help as well?
I'll test this tomorrow, but even if it helps I am not sure... Yes, this
way zone_reclaimable() and get_scan_count() will see the same numbers, but
how this can help to make zone_reclaimable() == F at the end?
Again, suppose that (say) ACTIVE list is empty but zone->vm_stat != 0
because there is something in per-cpu counter (so that _snapshot == 0).
This means that we sill continue to try to scan this list for no reason.
But Michal, let me repeat that I do not understand this code, so I can
be easily wrong.
Oleg.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: zone_reclaimable() leads to livelock in __alloc_pages_slowpath()
Date: Wed, 1 Jun 2016 01:56:26 +0200 [thread overview]
Message-ID: <20160531235626.GA24319@redhat.com> (raw)
In-Reply-To: <20160531125253.GK26128@dhcp22.suse.cz>
On 05/31, Michal Hocko wrote:
>
> On Sun 29-05-16 23:25:40, Oleg Nesterov wrote:
> >
> > This single change in get_scan_count() under for_each_evictable_lru() loop
> >
> > - size = lruvec_lru_size(lruvec, lru);
> > + size = zone_page_state_snapshot(lruvec_zone(lruvec), NR_LRU_BASE + lru);
> >
> > fixes the problem too.
> >
> > Without this change shrink*() continues to scan the LRU_ACTIVE_FILE list
> > while it is empty. LRU_INACTIVE_FILE is not empty (just a few pages) but
> > we do not even try to scan it, lruvec_lru_size() returns zero.
>
> OK, you seem to be really seeing a different issue than me.
quite possibly, but
> My debugging
> patch was showing when nothing was really isolated from the LRU lists
> (both for shrink_{in}active_list.
in my debugging session too. LRU_ACTIVE_FILE was empty, so there is nothing to
isolate even if shrink_active_list() is (wrongly called) with nr_to_scan != 0.
LRU_INACTIVE_FILE is not empty but it is not scanned because nr_to_scan == 0.
But I am afraid I misunderstood you, and you meant something else.
> > Then later we recheck zone_reclaimable() and it notices the INACTIVE_FILE
> > counter because it uses the _snapshot variant, this leads to livelock.
> >
> > I guess this doesn't really matter, but in my particular case these
> > ACTIVE/INACTIVE counters were screwed by the recent putback_inactive_pages()
> > logic. The pages we "leak" in INACTIVE list were recently moved from ACTIVE
> > to INACTIVE list, and this updated only the per-cpu ->vm_stat_diff[] counters,
> > so the "non snapshot" lruvec_lru_size() in get_scan_count() sees the "old"
> > numbers.
>
> Hmm. I am not really sure we can use the _snapshot version in lruvec_lru_size.
Yes, yes, I understand,
> But I am thinking whether we should simply revert 0db2cb8da89d ("mm,
> vmscan: make zone_reclaimable_pages more precise") in 4.6 stable tree.
> Does that help as well?
I'll test this tomorrow, but even if it helps I am not sure... Yes, this
way zone_reclaimable() and get_scan_count() will see the same numbers, but
how this can help to make zone_reclaimable() == F at the end?
Again, suppose that (say) ACTIVE list is empty but zone->vm_stat != 0
because there is something in per-cpu counter (so that _snapshot == 0).
This means that we sill continue to try to scan this list for no reason.
But Michal, let me repeat that I do not understand this code, so I can
be easily wrong.
Oleg.
next prev parent reply other threads:[~2016-05-31 23:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 20:28 zone_reclaimable() leads to livelock in __alloc_pages_slowpath() Oleg Nesterov
2016-05-20 20:28 ` Oleg Nesterov
2016-05-21 4:07 ` Tetsuo Handa
2016-05-21 4:07 ` Tetsuo Handa
2016-05-22 21:17 ` Oleg Nesterov
2016-05-22 21:17 ` Oleg Nesterov
2016-05-23 7:29 ` Michal Hocko
2016-05-23 7:29 ` Michal Hocko
2016-05-23 15:14 ` Oleg Nesterov
2016-05-23 15:14 ` Oleg Nesterov
2016-05-24 7:16 ` Michal Hocko
2016-05-24 7:16 ` Michal Hocko
2016-05-24 22:43 ` Oleg Nesterov
2016-05-24 22:43 ` Oleg Nesterov
2016-05-25 12:09 ` Michal Hocko
2016-05-29 21:25 ` Oleg Nesterov
2016-05-29 21:25 ` Oleg Nesterov
2016-05-31 12:52 ` Michal Hocko
2016-05-31 12:52 ` Michal Hocko
2016-05-31 23:56 ` Oleg Nesterov [this message]
2016-05-31 23:56 ` Oleg Nesterov
2016-06-01 10:00 ` Michal Hocko
2016-06-01 10:00 ` Michal Hocko
2016-06-01 21:38 ` Oleg Nesterov
2016-06-01 21:38 ` Oleg Nesterov
2016-06-02 15:11 ` Michal Hocko
2016-06-02 15:11 ` Michal Hocko
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=20160531235626.GA24319@redhat.com \
--to=oleg@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.