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

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 10 Feb 2023 13:24:02 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Yosry Ahmed <yosryahmed@...gle.com>
Cc:     Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH 2/2] zsmalloc: fine-grained inuse ratio based fullness
 grouping

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.

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.