Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1603642
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages |
| Date | 2017-03-17 22:50 +0100 |
| Message-ID | <tm7BD-4ei-5@gated-at.bofh.it> (permalink) |
| References | <tlfBf-73v-3@gated-at.bofh.it> <tm56O-2jb-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri 17-03-17 14:39:28, Johannes Weiner wrote:
> On Wed, Mar 15, 2017 at 07:36:48PM +0800, Yisheng Xie wrote:
> > @@ -100,6 +100,9 @@ struct scan_control {
> > /* Can cgroups be reclaimed below their normal consumption range? */
> > unsigned int may_thrash:1;
> >
> > + /* Did we have any memcg protected by the low limit */
> > + unsigned int memcg_low_protection:1;
>
> These are both bad names. How about the following pair?
>
> /*
> * Cgroups are not reclaimed below their configured memory.low,
> * unless we threaten to OOM. If any cgroups are skipped due to
> * memory.low and nothing was reclaimed, go back for memory.low.
> */
> unsigned int memcg_low_skipped:1
> unsigned int memcg_low_reclaim:1;
yes this is much better
>
> > @@ -2557,6 +2560,8 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
> > unsigned long scanned;
> >
> > if (mem_cgroup_low(root, memcg)) {
> > + sc->memcg_low_protection = 1;
> > +
> > if (!sc->may_thrash)
> > continue;
>
> if (!sc->memcg_low_reclaim) {
> sc->memcg_low_skipped = 1;
> continue;
> }
>
> > mem_cgroup_events(memcg, MEMCG_LOW, 1);
> > @@ -2808,7 +2813,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
> > return 1;
> >
> > /* Untapped cgroup reserves? Don't OOM, retry. */
> > - if (!sc->may_thrash) {
> > + if (sc->memcg_low_protection && !sc->may_thrash) {
>
> if (sc->memcg_low_skipped) {
> [...]
> sc->memcg_low_reclaim = 1;
you need to set memcg_low_skipped = 0 here, right? Otherwise we do not
have break out of the loop. Or am I missing something?
> goto retry;
> }
--
Michal Hocko
SUSE Labs
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Yisheng Xie <xieyisheng1@huawei.com> - 2017-03-15 12:50 +0100
Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Michal Hocko <mhocko@kernel.org> - 2017-03-15 13:50 +0100
Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Yisheng Xie <xieyisheng1@huawei.com> - 2017-03-16 11:10 +0100
Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Johannes Weiner <hannes@cmpxchg.org> - 2017-03-17 16:30 +0100
Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Michal Hocko <mhocko@kernel.org> - 2017-03-17 19:10 +0100
Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Johannes Weiner <hannes@cmpxchg.org> - 2017-03-17 19:50 +0100
Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Johannes Weiner <hannes@cmpxchg.org> - 2017-03-17 22:30 +0100
Re: [PATCH v4] mm/vmscan: more restrictive condition for retry in do_try_to_free_pages Michal Hocko <mhocko@kernel.org> - 2017-03-17 22:50 +0100
csiph-web