On (25/01/29 15:53), Yosry Ahmed wrote: > On Wed, Jan 29, 2025 at 03:43:46PM +0900, Sergey Senozhatsky wrote: > > This is Part II of the series [1] that makes zram read() and write() > > preemptible. This part focuses only zsmalloc because zsmalloc imposes > > atomicity restrictions on its users. One notable example is object > > mapping API, which returns with: > > a) local CPU lock held > > b) zspage rwlock held > > > > First, zsmalloc is converted to use sleepable RW-"lock" (it's atomic_t > > in fact) for zspage migration protection. Second, a new handle mapping > > is introduced which doesn't use per-CPU buffers (and hence no local CPU > > lock), does fewer memcpy() calls, but requires users to provide a > > pointer to temp buffer for object copy-in (when needed). Third, zram is > > converted to the new zsmalloc mapping API and thus zram read() becomes > > preemptible. > > > > [1] https://lore.kernel.org/linux-mm/20250127072932.1289973-1-senozhatsky@xxxxxxxxxxxx > > > > RFC -> v1: > > - Only zspage->lock (leaf-lock for zs_map_object()) is converted > > to a preemptible lock. The rest of the zspool locks remain the > > same (Yosry hated with passion the fact that in RFC series all > > zspool looks would become preemptible). > > Hated is a big word here, I was merely concerned about how the locking > changes would affect performance :P Yeah I'm just messing around :)
