Re: [PATCH 2/2] zsmalloc: fine-grained inuse ratio based fullness grouping

From: Yosry Ahmed <yosryahmed@google.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] zsmalloc: fine-grained inuse ratio based fullness grouping
Date: Thu, 9 Feb 2023 20:25:46 -0800	[thread overview]
Message-ID: <CAJD7tka3s84v9-ZA-OZkBkina6MByCSFnKXwv+hq8o8nZSZoyg@mail.gmail.com> (raw)
In-Reply-To: <Y+XG4mWPi4X9/hHZ@google.com>

On Thu, Feb 9, 2023 at 8:24 PM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> On (23/02/07 10:47), Sergey Senozhatsky wrote:
> > > >  enum fullness_group {
> > > > -       ZS_EMPTY,
> > > > -       ZS_ALMOST_EMPTY,
> > > > -       ZS_ALMOST_FULL,
> > > > -       ZS_FULL,
> > > > +       ZS_USAGE_0,
> > > > +       ZS_USAGE_10,
> > > > +       ZS_USAGE_20,
> > > > +       ZS_USAGE_30,
> > > > +       ZS_USAGE_40,
> > > > +       ZS_USAGE_50,
> > > > +       ZS_USAGE_60,
> > > > +       ZS_USAGE_70,
> > > > +       ZS_USAGE_80,
> > > > +       ZS_USAGE_90,
> > > > +       ZS_USAGE_99,
> > > > +       ZS_USAGE_100,
> > > >         NR_ZS_FULLNESS,
> > > >  };
> > > >
> > >
> > > Is there a reason why this can't be done with something like #define
> > > FULLNESS_GROUPS 10? We can make sure during build that (100 %
> > > FULLNESS_GROUPS == 0) to make our lives easier. I feel like the code
> > > will be much more concise and easier to navigate, instead of multiple
> > > enums and static arrays.
> >
> > I wanted to keep things the way they are to make reviews simpler.
> > We probably can do something more "disruptive" in a separate patch.
>
> Forgot to mention, I was also thinking about extending zsmalloc stats
> file and providing values for each fullness group per class, as opposed
> to current ALMOST_EMPTY and ALMOST_FULL stats, which don't tell much.

Makes sense.

>
> I can get rid of static const arrays and pass "begin / end" group IDs to
> functions that iterate fullness lists and pick the first head page, but
> I think that enum values will stay.

Do they have to stay for a technical reason or just to make reviews simpler?