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

[Barry Song]

On Wed, Aug 5, 2026 at 2:09 PM Sergey Senozhatsky
<senozhatsky@xxxxxxxxxxxx> wrote:
>
> Cc-ing Suleiman
>
> On (26/08/05 09:57), Barry Song 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. :-)
>
> 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.

proxy execution could only defer the preemption for the compression
and decompression, it wont address the potential long sleep of
zs-malloc. we should not do sleepable zs-malloc
within the mutex.

i will send v2 with more details.

Best Regards
Barry