Re: [RFC PATCH 2/2] zsmalloc: chain-length configuration should consider other metrics

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (26/01/05 16:01), Yosry Ahmed wrote:
> On Mon, Jan 05, 2026 at 04:23:39PM +0900, Sergey Senozhatsky wrote:
> > On (26/01/05 10:42), Sergey Senozhatsky wrote:
> > > On (26/01/02 18:29), Yosry Ahmed wrote:
> > > > On Thu, Jan 01, 2026 at 10:38:14AM +0900, Sergey Senozhatsky wrote:
> > > [..]
> > > > 
> > > > I worry that the heuristics are too hand-wavy
> > > 
> > > I don't disagree.  Am not super excited about the heuristics either.
> > > 
> > > > and I wonder if the memcpy savings actually show up as perf improvements
> > > > in any real life workload. Do we have data about this?
> > > 
> > > I don't have real life 16K PAGE_SIZE devices.  However, on 16K PAGE_SIZE
> > > systems we have "normal" size-classes up to a very large size, and normal
> > > class means chaining of 0-order physical pages, and chaining means spanning.
> > > So on 16K memcpy overhead is expected to be somewhat noticeable.
> > 
> > By the way, while looking at it, I think we need to "fix" obj_read_begin().
> > Currently, it uses "off + class->size" to detect spanning objects, which is
> > incorrect: size classes get merged, so a typical size class can hold a range
> > of sizes, using padding for smaller objects.  So instead of class->size we
> > need to use the actual compressed objects size, just in case if actual written
> > size was small enough to fit into the first physical page (we do that in
> > obj_write()).  I'll cook a patch.
> 
> We also need to handle zs_obj_read_end() to do the kunmap() call
> correctly.

Good catch, I realized that only after I started working on the patch.
We also need to account for inlined zs_handle.