linux-kernel - Re: [PATCH v3] mm: vmpressure: don't count proactive reclaim in vmpressure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 12 Jul 2022 15:51:54 -0700
From:   Yosry Ahmed <yosryahmed@...gle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Shakeel Butt <shakeelb@...gle.com>,
        Muchun Song <songmuchun@...edance.com>,
        Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        David Hildenbrand <david@...hat.com>,
        Miaohe Lin <linmiaohe@...wei.com>, NeilBrown <neilb@...e.de>,
        Alistair Popple <apopple@...dia.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Peter Xu <peterx@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Cgroups <cgroups@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH v3] mm: vmpressure: don't count proactive reclaim in vmpressure

On Wed, Jul 6, 2022 at 1:19 PM Yosry Ahmed <yosryahmed@...gle.com> wrote:
>
> On Fri, Jul 1, 2022 at 4:09 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > On Thu, 30 Jun 2022 08:30:44 +0000 Yosry Ahmed <yosryahmed@...gle.com> wrote:
> >
> > > vmpressure is used in cgroup v1 to notify userspace of reclaim
> > > efficiency events, and is also used in both cgroup v1 and v2 as a signal
> > > for memory pressure for networking, see
> > > mem_cgroup_under_socket_pressure().
> > >
> > > Proactive reclaim intends to probe memcgs for cold memory, without
> > > affecting their performance. Hence, reclaim caused by writing to
> > > memory.reclaim should not trigger vmpressure.
> > >
> > > ...
> > >
> > > --- a/mm/memcontrol.c
> > > +++ b/mm/memcontrol.c
> > > @@ -2319,6 +2319,7 @@ static unsigned long reclaim_high(struct mem_cgroup *memcg,
> > >                                 gfp_t gfp_mask)
> > >  {
> > >       unsigned long nr_reclaimed = 0;
> > > +     unsigned int reclaim_options = MEMCG_RECLAIM_MAY_SWAP;
> > >
> > >       do {
> > >               unsigned long pflags;
> > > @@ -2331,7 +2332,8 @@ static unsigned long reclaim_high(struct mem_cgroup *memcg,
> > >
> > >               psi_memstall_enter(&pflags);
> > >               nr_reclaimed += try_to_free_mem_cgroup_pages(memcg, nr_pages,
> > > -                                                          gfp_mask, true);
> > > +                                                          gfp_mask,
> > > +                                                          reclaim_options);
> >
> > It's a bit irksome to create all these unneeded local variables.  Why
> > not simply add the constant arg to the try_to_free_mem_cgroup_pages()
> > call?
> >
>
> I was trying to improve readability by trying to have consistent
> reclaim_options local variable passed into
> try_to_free_mem_cgroup_pages(), and also to avoid nested line-wrapping
> in cases where reclaim_options = MEMCG_RECLAIM_MAY_SWAP |
> MEMCG_RECLAIM_PROACTIVE (like in memory_reclaim()). Since you found it
> irksome, I obviously failed :)
>
> Will remove the local variables where possible and send a v4. Thanks
> for taking a look!
>
> > >               psi_memstall_leave(&pflags);
> > >       } while ((memcg = parent_mem_cgroup(memcg)) &&
> > >                !mem_cgroup_is_root(memcg));
> > > @@ -2576,7 +2578,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> > >       struct page_counter *counter;
> > >       unsigned long nr_reclaimed;
> > >       bool passed_oom = false;
> > > -     bool may_swap = true;
> > > +     unsigned int reclaim_options = MEMCG_RECLAIM_MAY_SWAP;
> > >       bool drained = false;
> > >       unsigned long pflags;
> > >
> > > @@ -2593,7 +2595,7 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask,
> > >               mem_over_limit = mem_cgroup_from_counter(counter, memory);
> > >       } else {
> > >               mem_over_limit = mem_cgroup_from_counter(counter, memsw);
> > > -             may_swap = false;
> > > +             reclaim_options &= ~MEMCG_RECLAIM_MAY_SWAP;
> >
> >         reclaim_options = 0
> >
> > would be clearer?
> >
>
> I feel like the current code is more clear to the reader and
> future-proof. If we can't swap, we want to remove the MAY_SWAP flag,
> we don't want to remove all existing flags. In this case it's the
> same, but maybe in the future it won't be and someone will miss
> updating this line. Anyway, I don't have a strong opinion, let me know
> what you prefer for v4.


Andrew, any preferences on this before I send v4?