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
| ||
|
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.
Powered by blists - more mailing lists