From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C24F0C0218D for ; Wed, 29 Jan 2025 15:54:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE7E06B02C5; Wed, 29 Jan 2025 10:53:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E97B76B02C6; Wed, 29 Jan 2025 10:53:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D86866B02C7; Wed, 29 Jan 2025 10:53:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BA1306B02C5 for ; Wed, 29 Jan 2025 10:53:59 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3A83980C5F for ; Wed, 29 Jan 2025 15:53:59 +0000 (UTC) X-FDA: 83060935398.16.DD61745 Received: from out-185.mta1.migadu.com (out-185.mta1.migadu.com [95.215.58.185]) by imf15.hostedemail.com (Postfix) with ESMTP id 61081A0009 for ; Wed, 29 Jan 2025 15:53:57 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=PY2YhJ1C; spf=pass (imf15.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.185 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738166037; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zPbcB/ReL4OJLrfoZPjpuxdzT5Wr23vwCJ1GYQnYaKA=; b=2I+R8XdBAxhkeG62imXRMAS1+BoczMqLQrl1w775RbY5xDXrKtE+kcJvV+YW+A1SgjncHI 3wf72GLMu49YkSf2cbYzX/vlYORY/kbPs/ZvYfY5tuWu/D7J5reZa8zuH1pfJRhE1vxSmL S4Ar/76qhruUVAXTlFCYIM9ztlVDRw4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=PY2YhJ1C; spf=pass (imf15.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.185 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738166037; a=rsa-sha256; cv=none; b=6N3KO/tNXIkkX1GLPx5HhGGk6UFrREopf/NdxLHEPXGgaKCmQEi2QFtzCTnQPEWas4/AhV Zmc1oOOpLvrGb0wi8BY9ayc/FJgvRQa8eDi/nlviR2ynJpISP6fBdaaM32f2VDj2gkvJXK nYHgqzEeqxhuRC0sU7Q2/4B5UR6np7o= Date: Wed, 29 Jan 2025 15:53:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1738166035; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zPbcB/ReL4OJLrfoZPjpuxdzT5Wr23vwCJ1GYQnYaKA=; b=PY2YhJ1CLqzhLcHhDvLmFGnZqszLk/j+3lpD4wH3iLH6Eqj0s+y83j2TBj8FlLhNdVnrHR nG8ltD4cyufr6fEq0Ev+sAw3+Z1xqWkQFTKn6Yu+1R/Gwb1jcUizQ1fcrig+elrs7oeaSD BD+OGdceHlJ+nwr+EmE5A2Q38AcZIu4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Sergey Senozhatsky Cc: Andrew Morton , Minchan Kim , Johannes Weiner , Nhat Pham , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv1 0/6] zsmalloc: preemptible object mapping Message-ID: References: <20250129064853.2210753-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250129064853.2210753-1-senozhatsky@chromium.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 61081A0009 X-Stat-Signature: rmpftjn57fak4364a5bkbkxnpuzdgsdb X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738166037-717087 X-HE-Meta: U2FsdGVkX1+8N2dz8nrCi1dJGW1Tj/IY12s1s57/7qbQtubkwHW6SvGAnNZ8jDQ4shymq7UfTyHVdq4/ZlCI7axnL5O1A8NNJVhr349YazJ6Le+M+3CBjSwdvRJpR1DSL0gBnE9AHol6GOpyGesnN6Cly5AqX+xWwfcEd+eTJNksdyeBPPmJAakw96NRexsliTuMx4+7tEjLFahKKsr4TNG3qedALCa6Mxf8yn5byWgU1lNQ1yoXUe6d8naV7Wm5YXtk5O04ip5ZUR9HYeJGIYqx/8Mh1MdL+dehOusrQmX12FeEc9lXs8hR2xRGtn+ArXDUpQuwYrVEDD5wTdbX39LcyiN7vU9WldUpl3ZL4EEtCWY97Jd+R1zd/WXD7pCfCAG5UDNm26NS9J1FJifuuYR4hFZNzRw5ZJxhRqqnLEbkNu4o4vnx14V04Sg0g31LyUuBUK7SYQ4FyCVijpWZSNRD889svO3kkTbqw3cfM6/ypQBwbUCHpe50Ie2dTsJGA7WrSaspgl1BQBpo+BBEQahvqbWHEFeHOnz6oi71mXsCdV2Y9jicedGBVY5M6ZFUTnGl+CnK68cRj5HUEEPcQfGJniearNmM+hR6jOkbaAbed4mUmxzkHhNCC/68194nUnzvkNoCxC3gF2Oy6Fw7hwJnT3l75wj7YTQ+6wCGW7WCe2O18zamTnw8Ap/VSRi4zCVEM/lf75WTKAmdvYyqdtCITArNKgUX/NzZ4pKG7GiqYDo3G0bvxayv3FNMgPnoHyiAkdIXyC6XvAvZ9f6PQfS3yB5vieVyigXcMOZ/cEVu5i7SyZAUDHElrdZ+KaqXjJLPfc6v1+pJ3VfWHpkGOfSdqLEUtIcA7zE/IQanCtYUIofaTgx9xeRO17OODlrPSbMwspLSl7q8w0DRDcolMB7XR8VX4nTg5+xvg86bj43X8XJs5X17DoScXruM0PfrKANXZNrclvHsxWMcaTD dGRfBxGF vbRNDB5lsIrS8mEHJtIO5+FrgVb5BykmIJ6dz1m7OlVEyeYtS2h9LIIsgYnal/3kTema3A2GtaeMkiBsGaVAgB9pmPGFZM9dgAy63rhNnUd+PHpkPDfxs7ews4RP4gI3UxE7XnNmdKN9/7r0CpGgex8s8A2lYsZG7qZewpVLolfOnA+BxjaT7UkhZZWwZuK6TfGkHsOaf6B82cIKrd8RuVaMLdZpisXo6CVQQNNMmfPxwd4n2cgRfzYL1SQMSUfNqZzpD X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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@chromium.org > > 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 > - New zs object mapping API (Yosry hated RFC API with passion). > We know have obj_read_begin()/obj_read_end() and obj_write(). > - obj_write() saves extra memcpy() calls for objects that span two > physical pages. > - Dropped zram deferred slot-free-notification handling (I hated > it with passion) > > Sergey Senozhatsky (6): > zsmalloc: factor out pool locking helpers > zsmalloc: factor out size-class locking helpers > zsmalloc: make zspage lock preemptible > zsmalloc: introduce new object mapping API > zram: switch to new zsmalloc object mapping API > zram: add might_sleep to zcomp API > > drivers/block/zram/zcomp.c | 6 +- > drivers/block/zram/zcomp.h | 2 + > drivers/block/zram/zram_drv.c | 28 +-- > include/linux/zsmalloc.h | 8 + > mm/zsmalloc.c | 372 ++++++++++++++++++++++++++-------- > 5 files changed, 311 insertions(+), 105 deletions(-) > > -- > 2.48.1.262.g85cc9f2d1e-goog >