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: Windows password security audit tool. GUI, reports in PDF.

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

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

On (23/02/06 17:02), Yosry Ahmed wrote:
[..]
> > A 1/10 difference in ratio between fullness groups is intentional
> > and critical for classes that have a high number of objs_per_zspage.
> > For instance, class-624 stores 59 objects per zspage. With a 1/10
> > ratio grouping, the difference in inuse values between the page
> > with the lowest and highest inuse in a single fullness group is
> > only 4 objects (2469 bytes), whereas a 1/5 ratio grouping would
> > result in a difference of 10 objects (6240 bytes).
> 
> 
> The memory extra overhead would be sizeof(list_head) * nr of classes *
> extra fullness groups = 16 * 255 * 6 = 24480 bytes ~= 24KB on a
> machine with 4096 page size. Sounds reasonable (although I wonder how
> it scales with PAGE_SIZE).

It should be slightly lower than that. We never have 255 classes,
because clases get merged. On a system with chain size of 10 we
have 141 classes, with chain size of 8 it's 119 and chain size of
16 gives us 192 size classes.

> >  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.