On Mon, Oct 31, 2022 at 02:40:59PM +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 > classes, improving compactness of the pool and redusing the > amount of memory zsmalloc pool uses. More on this in 0002 > commit message. Hi Sergey, I think the idea that break of fixed subpages in zspage is really good start to optimize further. However, I am worry about introducing per-pool config this stage. How about to introduce just one golden value for the zspage size? order-3 or 4 in Kconfig with keeping default 2? And then we make more efforts to have auto tune based on the wasted memory and the number of size classes on the fly. A good thing to be able to achieve is we have indirect table(handle <-> zpage) so we could move the object anytime so I think we could do better way in the end.
