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

On (26/08/05 15:50), Barry Song wrote:
> > > 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].
> 

[..]

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

This sounds interesting. I think all of the S/W backends that we use
have stateless decompression, so we probably can just split per-CPU
stream mutex for R and W paths w/o the need for any additional scratch
buffers.  Wanna give it a try?

Back to preemption:
Is there maybe a common hot preemption point where stream mutex owners
get scheduled out? E.g. inside zs_malloc()?