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

[Sergey Senozhatsky <senozhatsky@chromium.org>]

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].

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.

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

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

[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