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 C96FAC0218C for ; Mon, 27 Jan 2025 07:30:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62B67280126; Mon, 27 Jan 2025 02:30:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DB8D2800DA; Mon, 27 Jan 2025 02:30:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A33F280126; Mon, 27 Jan 2025 02:30:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 28CD72800DA for ; Mon, 27 Jan 2025 02:30:14 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A775DB0E54 for ; Mon, 27 Jan 2025 07:30:13 +0000 (UTC) X-FDA: 83052408306.15.707B58B Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf03.hostedemail.com (Postfix) with ESMTP id C8E3B2000C for ; Mon, 27 Jan 2025 07:30:11 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=fwMeiESF; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.170 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737963011; a=rsa-sha256; cv=none; b=sKlSuipS+9hy/XUl7nLNju9Rm7p/SbeybQJDAbCLtLBg86OmZq+Xf6bT/hjDGNn5elg9A6 RsCQS1V3rwqlG9u9M6DHpo6UMcnKBIxnha7nvfQA1UzeT/5agpSjxSGw2UwQDmJvHhYktN Qwy7giMEzd3v9nRmjgWM5e3L93Hu+2I= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=fwMeiESF; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.170 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737963011; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5g614UtqxTvOkBYeQdwAP9Uo/j0Alc44lQaUMvbAkkk=; b=QnZQAOnim72nlQpxKedj3juvwSwei2r2D3ZTwmNwcFGi7m2NxM5DsiKqj1W1u0GWN7Q5kj 3UG6E2LS7tLALNhE65grtOTMTkmIXVe6AqMYT7LYM9GslwUrDS4bi6Lyb6VEqtzSgUVH00 xlFXZagGfRUpjYlYTpMhrBt3ItC3xdA= Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-21628b3fe7dso69334405ad.3 for ; Sun, 26 Jan 2025 23:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1737963010; x=1738567810; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5g614UtqxTvOkBYeQdwAP9Uo/j0Alc44lQaUMvbAkkk=; b=fwMeiESF76m6mNMa6N2kxZNv6QCyJD3mghbRmBwBDeehBHYVXK83adyAs5dgKxWt+l qQEC3SByrd/m4xIvd6yLRhb9n2VwBSD07hbjIHTZKpsXadFPc1b1TeR9Jga0FoUkFIiR vVpwoTYyMc4wwHGylqJIS9JJIRnqLAcuNgYRs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737963010; x=1738567810; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5g614UtqxTvOkBYeQdwAP9Uo/j0Alc44lQaUMvbAkkk=; b=vmFqtBoJGdpC7RTZ8v0YiMceiUQM4a552qfE6M56XGpukj4LtOHx0HFYx6OyRygOQK PBiaLAzOHpVpkKpfc7LGShX4xG6LtoqYtkO+mfwmAur2rhjxkYy8mVjjY5ufaxBwcdDP 6An/PwLOxSHPa/ip4hAYJSn8YNChs6STrIj/enCmEZMibJYSlwdJLOKg4iQH9IEXPBWE Xt5O8VYh/+sre7GsPr0WYQavEZc9sTGo17ARMd3v2N4Y+NuzQNWgNaxnsEJR49Ust01I Nj3Nq91/H1RF3IZ/je6yCQnSqFvjJ1ZjbC39toa2Iyoaqbj2Lk76RTnjx55CRZh9tywr B66A== X-Gm-Message-State: AOJu0YymJV8+XGgKtd6cCpVB+2xrmuIc4ziNQ0NOOJEUiKE180cqtaib CuZXqbnctcKUVJ1c0PhV0iAD6RivWFIxBXTggtpEKE5VtIBtsQsYZUqu2SB9/A== X-Gm-Gg: ASbGnculCJYgxN06Etcurk90KovtfzHT3gTskgbNozlh+tURI0OIT2QVU4HrxozYRtY TnesU5rWf0NQIe6frmm+GwB6Alq8u7TDh13jbt76hMi2MWV97WWXqMJhRHNqo5v23cbzZKBav8Y 1Q7WfLzVKnYgsBfI1fCIHpzqfE2TAzlbGamF5fD+D/KKTlZTzExSIYQJP0xv9h4J1HXhg7K9hIq yEfiC/4/T4aCcWMTbIMmrN7uDmXuNyoZG70XP9whGQ+fCgCK9UjQ87OL/9IJDg47niCaAira+ud YrpKmw0= X-Google-Smtp-Source: AGHT+IGKyeWS3mv+loODSXHq45Ym+6tplx4pvP6lVRL0eZv4C+tLZFBWcDTabbbQlUIiu02lYNkogw== X-Received: by 2002:a05:6a00:2294:b0:728:e745:23cd with SMTP id d2e1a72fcca58-72daf92bbd7mr61064828b3a.3.1737963010417; Sun, 26 Jan 2025 23:30:10 -0800 (PST) Received: from localhost ([2401:fa00:8f:203:566d:6152:c049:8d3a]) by smtp.gmail.com with UTF8SMTPSA id 41be03b00d2f7-ac48ea371dasm5724120a12.12.2025.01.26.23.30.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Jan 2025 23:30:10 -0800 (PST) From: Sergey Senozhatsky To: Andrew Morton , Minchan Kim Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: [PATCHv2 6/9] zram: permit reclaim in zstd custom allocator Date: Mon, 27 Jan 2025 16:29:17 +0900 Message-ID: <20250127072932.1289973-7-senozhatsky@chromium.org> X-Mailer: git-send-email 2.48.1.262.g85cc9f2d1e-goog In-Reply-To: <20250127072932.1289973-1-senozhatsky@chromium.org> References: <20250127072932.1289973-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C8E3B2000C X-Stat-Signature: weraamm4niof3fri675n68ubnpw9ba8e X-Rspam-User: X-HE-Tag: 1737963011-221895 X-HE-Meta: U2FsdGVkX1+3iWcTR7494axOdxcppL+6qtHq5gLqckeuNbnMbDdE9oQfo3FhLZWDpVCjj0OrIKiOku9m8EjP7B0ygbRDl3Mj4dmqXoF1bquqZl9nfuFTMi3CBWTx/D5s0ZdxW3aF/zewKw5udWtBOIjzZsnfKBg2DixgNrlRy2R6qFEyoUS/A1ZZXCfh8qZircavWQhrdxmoo6uEjQ3G671iIjnGTziDTodRloxmJxFN3Dd7shKHiHv2DFsZwNzlmAPD3KG5liq9XYC0JyCZQTvIz2cdYHxbL4MBPCFpIWvQTVzoKEwg3qa5DgkwUZyUlaa2BNN7C0Lpfd/oju0rVk+mfnd7aK22n8sQgJTOUJ9936hHph1z7FvcEKM3hOvISy48qtFkUbVj1lPRfr+T7BeoLTxeK66yLCWspGjmtn2bwxji//sS/hap3DcUu0teAv1oS8da96Z6NOI8UeNCsC1dk0NE342lH88kb4rxlVoe2EYYt1o0MiFz1kxNYbDQIQ1DX0/jhv2ctnFFNzU4hp1oZaA89EKDpu3ysKwgalZzuqZVJvFd+hS5ez5jS67Vhcp0qWpgemnc7bf7h/WybsdsQlMX5v5Dv7imf6xHBlxBppK2T5dgHa4D6PlCrJ6KmwD2VPVErcWtDviQlcS8ptYRFViVVu3GpmswAbB5Loji1o0znU8aC54xb7FlzzvJs3uh4VyvNmeJlJRYfOoxO0S2kMqR/RD1cpNCkGDcw5P6cKzvdU3w/GOGSCF+AlLgoJM/g7EHdXHYipl/pnYEZ+EJlo17OK8uB8o9D3GMvqEa1/NS4RvS4jISWWwrvp9Tq9iyGxyG/G2uC9TjpydzMaKZu1QfD8MxgcfX9VGGPB3S5cmzZ94C7wrMdKymJ1dCwxJx3r+loa9mBTb4kMAZwcJd6rL5vZYnO/2sPSXSEd2Mxjrs0dZuLCKfGy3NZkcRqzcrzrIBduaAAa5CznW xEvFw1M2 P8BGvIxtceBsp8ORP3K5Mx5HgSvRbS5AlxYz+J9Wxb+X0p7zBxItBVJCVbmHgitpGELUzB+El6Oby0eEEU9syjaMheU5LgboJkYFFb7uWSxPF7vsC96WjvSvPSwH4DPebucD/C2PzGtmMLblbnoiyhV19opSYhULGoW/ifsdt55nRZyZtQ6v58HlZ8QHTuHINdl1r0qifrz40ll2X5Lk3I7ih/EmcOtbvx+8im0yetTXo2kmPtNQhyZAi17hMRnHUwnVfXeDAAok2cXJ5cJuWx4yT7AlHU6cf/nzJsj472jCPqWdShOj8lqVTzg== 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: When configured with pre-trained compression/decompression dictionary support, zstd requires custom memory allocator, which it calls internally from compression()/decompression() routines. This was a tad problematic, because that would mean allocation from atomic context (either under entry spin-lock, or per-CPU local-lock or both). Now, with non-atomic zram write(), those limitations are relaxed and we can allow direct and indirect reclaim during allocations. The tricky part is zram read() path, which is still atomic in one particular case (read_compressed_page()), due to zsmalloc handling of object mapping. However, in zram in order to read() something one has to write() it first, and write() is when zstd allocates required internal state memory, and write() path is non-atomic. Because of this write() allocation, in theory, zstd should not call its allocator from the atomic read() path. Keep the non-preemptible branch, just in case if zstd allocates memory from read(), but WARN_ON_ONCE() if it happens. Signed-off-by: Sergey Senozhatsky --- drivers/block/zram/backend_zstd.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/block/zram/backend_zstd.c b/drivers/block/zram/backend_zstd.c index 1184c0036f44..53431251ea62 100644 --- a/drivers/block/zram/backend_zstd.c +++ b/drivers/block/zram/backend_zstd.c @@ -24,19 +24,14 @@ struct zstd_params { /* * For C/D dictionaries we need to provide zstd with zstd_custom_mem, * which zstd uses internally to allocate/free memory when needed. - * - * This means that allocator.customAlloc() can be called from zcomp_compress() - * under local-lock (per-CPU compression stream), in which case we must use - * GFP_ATOMIC. - * - * Another complication here is that we can be configured as a swap device. */ static void *zstd_custom_alloc(void *opaque, size_t size) { - if (!preemptible()) + /* Technically this should not happen */ + if (WARN_ON_ONCE(!preemptible())) return kvzalloc(size, GFP_ATOMIC); - return kvzalloc(size, __GFP_KSWAPD_RECLAIM | __GFP_NOWARN); + return kvzalloc(size, GFP_NOIO | __GFP_NOWARN); } static void zstd_custom_free(void *opaque, void *address) -- 2.48.1.262.g85cc9f2d1e-goog