Documentation/admin-guide/blockdev/zram.rst | 31 +++++-- drivers/block/zram/zram_drv.c | 44 ++++++++- drivers/block/zram/zram_drv.h | 2 + include/linux/zsmalloc.h | 15 +++- mm/zsmalloc.c | 98 +++++++++++++-------- 5 files changed, 145 insertions(+), 45 deletions(-)
Hello, Some use-cases and/or data patterns may benefit from larger zspages. Currently the limit on the number of physical pages that are linked into a zspage is hardcoded to 4. Higher limit changes key characteristics of a number of the size clases, improving compactness of the pool and redusing the amount of memory zsmalloc pool uses. For instance, the huge size class watermark is currently set to 3264 bytes. With order 3 zspages we have more normal classe and huge size watermark becomes 3632. With order 4 zspages huge size watermark becomes 3840. Commit #1 has more numbers and some analysis. Sergey Senozhatsky (6): zsmalloc: turn zspage order into runtime variable zsmalloc/zram: pass zspage order to zs_create_pool() zram: add pool_page_order device attribute Documentation: document zram pool_page_order attribute zsmalloc: break out of loop when found perfect zspage order zsmalloc: make sure we select best zspage size Documentation/admin-guide/blockdev/zram.rst | 31 +++++-- drivers/block/zram/zram_drv.c | 44 ++++++++- drivers/block/zram/zram_drv.h | 2 + include/linux/zsmalloc.h | 15 +++- mm/zsmalloc.c | 98 +++++++++++++-------- 5 files changed, 145 insertions(+), 45 deletions(-) -- 2.38.0.135.g90850a2211-goog
On (22/10/25 01:12), Sergey Senozhatsky wrote: > Sergey Senozhatsky (6): > zsmalloc: turn zspage order into runtime variable > zsmalloc/zram: pass zspage order to zs_create_pool() > zram: add pool_page_order device attribute > Documentation: document zram pool_page_order attribute > zsmalloc: break out of loop when found perfect zspage order > zsmalloc: make sure we select best zspage size Andrew, I want to replace the last 2 patches in the series: I think we can drop `usedpc` calculations and instead optimize only for `waste` value. Would you prefer me to resend the entire instead?
On (22/10/25 13:30), Sergey Senozhatsky wrote:
> On (22/10/25 01:12), Sergey Senozhatsky wrote:
> > Sergey Senozhatsky (6):
> > zsmalloc: turn zspage order into runtime variable
> > zsmalloc/zram: pass zspage order to zs_create_pool()
> > zram: add pool_page_order device attribute
> > Documentation: document zram pool_page_order attribute
> > zsmalloc: break out of loop when found perfect zspage order
> > zsmalloc: make sure we select best zspage size
>
> Andrew, I want to replace the last 2 patches in the series: I think
> we can drop `usedpc` calculations and instead optimize only for `waste`
> value. Would you prefer me to resend the entire instead?
Andrew, let's do it another way - let's drop the last patch from the
series. But only the last one. The past was a last minute addition to
the series and I have not fully studied it's impact yet. From a
preliminary research I can say that it improves zsmalloc memory usage
only for order 4 zspages and has no statistically significant impact
on order 2 nor order 3 zspages.
Synthetic test, base get_pages_per_zspage() vs 'waste' optimized
get_pages_per_zspage() for order 4 zspages:
x zram-order-4-memused-base
+ zram-order-4-memused-patched
+----------------------------------------------------------------------------+
|+ + + + x xx x|
| |___________A_______M____| |____M_A______| |
+----------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 4 6.3960678e+08 6.3974605e+08 6.3962726e+08 6.3965082e+08 64101.637
+ 4 6.3902925e+08 6.3929958e+08 6.3926682e+08 6.3919514e+08 120652.52
Difference at 95.0% confidence
-455680 +/- 167159
-0.0712389% +/- 0.0261329%
(Student's t, pooled s = 96607.6)
If I will have enough confidence in that patch I will submit it
separately, with a proper commit message and clear justification.
On Tue, Oct 25, 2022 at 01:12:07AM +0900, Sergey Senozhatsky wrote: > Hello, > > Some use-cases and/or data patterns may benefit from > larger zspages. Currently the limit on the number of physical > pages that are linked into a zspage is hardcoded to 4. Higher > limit changes key characteristics of a number of the size > clases, improving compactness of the pool and redusing the > amount of memory zsmalloc pool uses. > > For instance, the huge size class watermark is currently set > to 3264 bytes. With order 3 zspages we have more normal classe > and huge size watermark becomes 3632. With order 4 zspages > huge size watermark becomes 3840. > > Commit #1 has more numbers and some analysis. > > Sergey Senozhatsky (6): > zsmalloc: turn zspage order into runtime variable > zsmalloc/zram: pass zspage order to zs_create_pool() > zram: add pool_page_order device attribute > Documentation: document zram pool_page_order attribute > zsmalloc: break out of loop when found perfect zspage order > zsmalloc: make sure we select best zspage size > > Documentation/admin-guide/blockdev/zram.rst | 31 +++++-- > drivers/block/zram/zram_drv.c | 44 ++++++++- > drivers/block/zram/zram_drv.h | 2 + > include/linux/zsmalloc.h | 15 +++- > mm/zsmalloc.c | 98 +++++++++++++-------- > 5 files changed, 145 insertions(+), 45 deletions(-) > Sorry, I can't cleanly apply this patch series due to conflicts in patch [1/6]. On what tree and commit the series is based? -- An old man doll... just what I always wanted! - Clara
On (22/10/25 10:26), Bagas Sanjaya wrote: > > Sorry, I can't cleanly apply this patch series due to conflicts in > patch [1/6]. On what tree and commit the series is based? next-20221024
On 10/25/22 10:42, Sergey Senozhatsky wrote: > On (22/10/25 10:26), Bagas Sanjaya wrote: >> >> Sorry, I can't cleanly apply this patch series due to conflicts in >> patch [1/6]. On what tree and commit the series is based? > > next-20221024 Hmm, still can't be applied (again patch [1/6] is the culprit). Please rebase on top of mm-everything. Don't forget to pass --base to git-format-patch(1) so that I know the base commit of this series. Thanks. -- An old man doll... just what I always wanted! - Clara
© 2016 - 2026 Red Hat, Inc.