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

[Sergey Senozhatsky <senozhatsky@chromium.org>]

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)?