[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tbvushbdn7nzitey3uy6humdndd6247r4544ngqkds3cr447e6@prnla4edwxmk>
Date: Mon, 8 Sep 2025 21:18:01 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>,
Vitaly Wool <vitaly.wool@...sulko.se>
Cc: Vlastimil Babka <vbabka@...e.cz>, hannes@...xchg.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>, Sergey Senozhatsky <senozhatsky@...omium.org>
Subject: Re: [PATCH 0/3] mm: remove zpool
On (25/09/06 14:25), Sergey Senozhatsky wrote:
> On (25/09/05 19:57), Yosry Ahmed wrote:
> > I think Android uses zram+zsmalloc with 16K pages. Perhaps Sergey could
> > confirm.
>
> I'm not working on android directly,
>
> 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.
Powered by blists - more mailing lists