Re: [RFC PATCH] zram: avoid preemption with CPU-based compression backends

On Wed, Aug 5, 2026 at 1:21 PM Sergey Senozhatsky
<[email protected]> wrote:
>
> Hi Barry,
>
> On (26/08/05 17:09), Barry Song wrote:
> > > > This report shows that the zram mutex has become the top lock
> > > > contributing to UI frame drops, even surpassing mmap_lock, which we
> > > > are also addressing in multiple threads. :-)
> > >
> > > Any chance you can share more details?  Are there perhaps RT tasks
> > > in the mix, priority inversion, starvations and so on?  Can proxy
> > > execution address any of those (if it has relevance to the report
> > > you are looking at)?
> >
> > Hi Sergey,
> >
> > talked with our engineers reporting the issue. i believe it is all
> > about priority inversion.
> > proxy execution wont resolve it as we have a sleepable zs-malloc
> > within the mutex.
> >  i believe i need v2 to release the mutex before doing the 2nd stage
> > zs_malloc with
> > direct reclaim.
>
> Well, we cannot just drop the stream mutex and do sleepable zsmalloc
> allocation, because this will invalidate compression buffer.  So we
> then will need to do re-compression.  Something that I was really
> happy to drop [1].

We used to do that by an temp GFP_ATOMIC buffer and memcpy:
https://lore.kernel.org/all/[email protected]/

As long as we copy `zstrm->buffer` to a temporary buffer, we are
free to go anywhere afterwards.

BTW, I wonder if compression and decompression could use separate
mutexes. That way, a sleepable zs_malloc() in the compression path
would not block decompression, which is the more latency-sensitive
operation.

>
> Is there any we can do apart from making zram and zsmalloc atomic
> again?  It's hard to believe that this priority inversion hits
> only zram and no other locks in the system.

It affects binder, mmap, and other paths. Some of them have already
been addressed in various ways. One common approach is to move
slow operations out of critical sections.

>
> I really really really don't want to return back to atomic
> zram/zsmalloc.

Let's not go back to atomic again. :-)

From what I can see, mm/zswap.c uses a non-sleepable zs_malloc(),
which likely helps avoid this problem. If that allocation fails,
zswap can still fall back to writing the page back to disk.
For zram, however, a failure of the non-sleepable zs_malloc() would
mean the swapout() operation itself fails.

>
> Is the report you are talking about some test or is it a real
> world scenario?

It happens in real-world scenarios as well as during testing.
For example, if you flash a Pixel 6 with an image containing those
non-atomic commits, the zram mutex becomes a bottleneck. Hongru
reported it as the top source of UI frame drops on Pixel 6, as shown
in the attached zram-mutex.png.

On our OEM devices, it is also a serious problem.

>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/block/zram/zram_drv.c?h=v6.1.180#n1376

Thanks
Barry