linux-kernel - Re: [PATCH] mm: throttle and inc min_seq when both page types reach MIN_NR

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGWkznGBWxVD0La5PArU1F2Q1Tqk40EGP1V0+jRiLNaxWy5zbg@mail.gmail.com>
Date: Fri, 11 Oct 2024 16:02:37 +0800
From: Zhaoyang Huang <huangzhaoyang@...il.com>
To: Yu Zhao <yuzhao@...gle.com>
Cc: "zhaoyang.huang" <zhaoyang.huang@...soc.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, steve.kang@...soc.com
Subject: Re: [PATCH] mm: throttle and inc min_seq when both page types reach MIN_NR_GENS

On Fri, Oct 11, 2024 at 12:37 AM Yu Zhao <yuzhao@...gle.com> wrote:
>
> On Wed, Oct 9, 2024 at 1:50 AM zhaoyang.huang <zhaoyang.huang@...soc.com> wrote:
> >
> > From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> >
> > The test case of [1] leads to system hang which caused by a local
> > watchdog thread starved over 20s on a 5.5GB RAM ANDROID15(v6.6)
> > system. This commit solve the issue by have the reclaimer be throttled
> > and increase min_seq if both page types reach MIN_NR_GENS, which may
> > introduce a livelock of switching type with holding lruvec->lru_lock.
> >
> > [1]
> > launch below script 8 times simutanously which allocates 1GB virtual
> > memory and access it from user space by each thread.
> > $ costmem -c1024000 -b12800 -o0 &
> >
> > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> > ---
> >  mm/vmscan.c | 16 ++++++++++++++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index cfa839284b92..83e450d0ce3c 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4384,11 +4384,23 @@ static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
> >         int remaining = MAX_LRU_BATCH;
> >         struct lru_gen_folio *lrugen = &lruvec->lrugen;
> >         struct mem_cgroup *memcg = lruvec_memcg(lruvec);
> > +       struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> >
> >         VM_WARN_ON_ONCE(!list_empty(list));
> >
> > -       if (get_nr_gens(lruvec, type) == MIN_NR_GENS)
> > -               return 0;
> > +       if (get_nr_gens(lruvec, type) == MIN_NR_GENS) {
> > +               /*
> > +                * throttle for a while and then increase the min_seq since
> > +                * both page types reach the limit.
> > +                */
>
> Sorry but this isn't going to work because in try_to_inc_min_seq(), there is
>    `while (min_seq[type] + MIN_NR_GENS <= lrugen->max_seq) {`
> to prevent reclaimers from evicting hot memory -- they need to do aging first.
Thanks for heads up. What I thought was assuming there is a running
reclaimer will do the aging and the throttled reclaimers increase the
min_seq when scheduled back and move on. Or could we just drop the
lock and throttle for a while to avoid a livelock on 'type = !type'
with holding the lock?

>
> >
> > +               if (get_nr_gens(lruvec, !type) == MIN_NR_GENS) {
> > +                       spin_unlock_irq(&lruvec->lru_lock);
> > +                       reclaim_throttle(pgdat, VMSCAN_THROTTLE_ISOLATED);
> > +                       spin_lock_irq(&lruvec->lru_lock);
> > +                       try_to_inc_min_seq(lruvec, get_swappiness(lruvec, sc));
> > +               } else
> > +                       return 0;
> > +       }
> >
> >         gen = lru_gen_from_seq(lrugen->min_seq[type]);
> >
> > --
> > 2.25.1
> >