On (22/11/10 14:25), Minchan Kim wrote: > On Mon, Oct 31, 2022 at 02:41:03PM +0900, Sergey Senozhatsky wrote: > > We will permit per-pool configuration of pages per-zspage value, > > which changes characteristics of the classes and moves around > > huge class size watermark. Thus huge class size needs to be > > a per-pool variable. > > I think part of code in previous patch should move here since > you are creating the feature in this patch: What do you mean? This patch - make huge_class_size a pool value - looks completely independent to me. > BTW, I am wondering we really need to jump the per-pool config > option over global general golden ratio and/or smarter approach > to optimize transparently depending on how much memory we have > wasted. I like the per-zspool value. Dynamic zspage sizing is going to be very very difficult if possible at all. With different zspage limits we create different size class clusters and we also limit huge size class watermark. So if we say, increase the zspage length value, then we have more size classes: but in order for us to actually start saving memory we need to move objects that waste memory in previous cluster configuration to new classes. It's even more complex with huge objects. When we say move huge size class watermark from 3264 to 3632 then in order to actually save memory we need to recompress huge objects and put them into size classes that are between 3264 and 3632. And that's only half. We also can lower the zspage length limit and we'll have less size classes (because they merge more) and move huge size class watermark from 3632 back to 3264. How do we handle this? I really think that per-zspool knob is the easiest way. And it doesn't block us from doing any improvements in the future.
