Re: [PATCH 0/3] mm: remove zpool

[Sergey Senozhatsky]

On (25/09/13 15:55), Vitaly Wool wrote:
> >>> I can confirm that android uses zram+zsmalloc.  As of 16K pages, there
> >>> was a way to toggle 16k pages on android (via system settings), I don't
> >>> know if this is the default now.
> >> 
> >> While I don't know what zsmalloc struggles Vitaly is referring to in
> >> particular, off the top of my head, zsmalloc does memcpy()'s for objects
> >> that span multiple pages, when zsmalloc kmap()'s both physical pages and
> >> memcpy()'s chunks of the object into a provided buffer. With 16K pages
> >> we can have rather larger compressed objects, so those memcpy() are likely
> >> more visible.  Attacking this would be a good idea, I guess.
> > 
> > Yeah I personally think attacking whatever problems zsmalloc has with
> > 16K pages is the way to go.
> 
> Well, there is a way out for 16+K pages, that being:
> * restricting zsmalloc to not have objects spanning across 2 pages

Yeah, the big problem with spanning objects is memcpy()-s, which we
currently need to do because zsmalloc() users expect linear address
from zs_map().  This doesn't need to be so, however [1], as zsmalloc()
can return SG-list instead and then upper layers (crypto/zcomp) should
handle that.

I have to admit, I haven't looked at zblock, so I don't know how
zblock handles it.  I'll try to look at it.

> * reworking size_classes based allocation to have uneven steps

If I understand you correctly, I thought about it briefly while
working on configurable zspage chain size [2], I think I even briefly
chatted with Minchan on "should we open code size classes instead?".
Then I looked at clustering (size_classes grouping and distribution)
and it wasn't too bad.  However, I don't think I looked at 16K setups,
things might be sad there.  Another thing in my to-look-at list.

While looking at size-classes clustering, I also sort of thought
about limiting zspages to one single page, so that zspages would
be a collection of fixed size chunks and each zspage would maintain
a bitmap of used/unused chinks, so that we can pack any objects into
zspage instead of "one particular size class".  But this has never
been materialized in any way,

> * as a result of the above, organising binary search for the right size object
>
> This will effectively turn zsmalloc into zblock, with some extra cruft that makes it far less comprehensible.

Is v4 [3] the most recent zblock version?

[1] https://lore.kernel.org/all/Z8K10w-6fIpDhYc6@xxxxxxxxxxxxxxxxxxx
[2] https://lore.kernel.org/all/20230118005210.2814763-4-senozhatsky@xxxxxxxxxxxx
[3] https://lore.kernel.org/all/20250412154207.2152667-1-vitaly.wool@xxxxxxxxxxx