Re: [PATCH 1/8] mm/mglru: consolidate common code for retrieving evitable size

[Kairui Song <ryncsn@gmail.com>]

On Sat, Mar 21, 2026 at 3:53 AM Axel Rasmussen <axelrasmussen@google.com> wrote:
>
> For what it's worth, I applied the full series and ran it through some
> basic functional testing, I didn't see any bugs or regressions from
> that.
>
> Unfortunately, the best signal would be actually deploying it under
> some real serving workloads, but the latency for me to do that + get
> results is like order(weeks) and I suspect you don't want to wait that
> long. :)
>
> This particular commit looks good besides one minor nitpick:
>
> Reviewed-by: Axel Rasmussen <axelrasmussen@google.com>

Thanks! Usually I ran the series through a about 2 day long stress
test matrix, and similar code has been deployed to our production
fleet for months. Just didn't find enough time to push these upstream.
Glad to see we are making progress to improve MGLRU upstream.

> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index 33287ba4a500..d7fc7f1fe06d 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -4078,27 +4078,33 @@ static void set_initial_priority(struct pglist_data *pgdat, struct scan_control
> > >       sc->priority = clamp(priority, DEF_PRIORITY / 2, DEF_PRIORITY);
> > >  }
> > >
> > > -static bool lruvec_is_sizable(struct lruvec *lruvec, struct scan_control *sc)
> > > +static long lruvec_evictable_size(struct lruvec *lruvec, int swappiness)
> > >  {
>
> Since `total` is unsigned long, should this function likewise return
> `unsigned long`? It seems ideal to avoid conversions unless there's a
> good reason to do so.

Ah nice catch, that would avoid an implicit casting, I think it has no
effect but wIll update in V2.