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

[Barry Song]

On Wed, Aug 5, 2026 at 9:27 AM Sergey Senozhatsky
<senozhatsky@xxxxxxxxxxxx> wrote:
>
> On (26/08/05 08:55), Barry Song (Xiaomi) wrote:
> > Since commit 2efa9e9eb4db ("zram: permit preemption with active
> > compression stream"), a major Android regression has been reported.
> >
> > The reason is that compression/decompression is now sleepable and
> > preemptible. This means a stream may be migrated to another CPU or
> > be preempted while holding the stream mutex. As a result, high
> > priority UI threads may get stuck waiting for the mutex during swap-in.
> [..]
> > We add an async flag (currently false for almost all backends) to
> > indicate whether a backend is asynchronous. For synchronous
> > backends, we use preempt_disable() in the !PREEMPT_RT case. A
>
> I wonder what does that report say.  Is that what I think it is
> (we discussed something RT related privately recently)?

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. :-)

Locally, we have reverted the patch, but for upstream we still need
to find a proper solution.