Re: [RFC PATCH] zram: avoid preemption with CPU-based compression backends
Sergey Senozhatsky <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <[email protected]> |
Hello, On (26/08/14 08:07), Barry Song wrote: > > On (26/08/05 08:55), Barry Song (Xiaomi) wrote: > > > @@ -128,14 +128,20 @@ struct zcomp_strm *zcomp_stream_get(struct zcomp *comp) > > > * so then unlock and re-try on the current CPU. > > > */ > > > mutex_lock(&zstrm->lock); > > > + if (!comp->ops->async && !IS_ENABLED(CONFIG_PREEMPT_RT)) > > > + preempt_disable(); > > > > We take slot_lock(), which is preemptible, under stream lock on > > some paths. > > Hi Sergey, > > As promised in [1], those patches are still under testing on real > Android phones. However, I'm quite curious which path takes > slot_lock while holding the zstream lock Oh, I think you are right. We do the opposite: stream lock under slot lock, and we also do the stream lock -> zsmalloc lock/unlock -> stream unlock -> slot lock/unlock chain. But it doesn't look like we ever do stream lock -> slot lock, you are right. Sorry for the confusion.