From patchwork Wed Jan 22 05:57:42 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergey Senozhatsky X-Patchwork-Id: 13946861 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 C9A51C02182 for ; Wed, 22 Jan 2025 05:59:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 583246B0093; Wed, 22 Jan 2025 00:59:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 531F36B0095; Wed, 22 Jan 2025 00:59:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D3A56B0096; Wed, 22 Jan 2025 00:59:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1F8796B0093 for ; Wed, 22 Jan 2025 00:59:28 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CC8E7C12FA for ; Wed, 22 Jan 2025 05:59:27 +0000 (UTC) X-FDA: 83034035574.30.156ACF4 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf24.hostedemail.com (Postfix) with ESMTP id EEDC2180008 for ; Wed, 22 Jan 2025 05:59:25 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Y1UBDom+; spf=pass (imf24.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737525566; 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=MU55qMB62NlP1Hfg8Lf4TsS0i/+gjPtdvpdv0f7R4WY=; b=DQ9V7ygXJOVMwdZ0DOcPM76jISbFL3+PUQX2VpW+ti+PO4rdqK9fbUg29sIjtSCs5wzoSs /ik8wZcosmqW768vyhuE2aZbwzqbKm9wshX3BSRjYiZLXBjJLGvmn7DS/Irgw2+pUZ/vbN tsMl+3/Q8WDiS9xCIKVWF2gsXO8uXCI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737525566; a=rsa-sha256; cv=none; b=tBU8NAtj99XTzSITs6Ai+sl3ePgIMgqnckBsCvazr9kZX9FjM0gzvHL1H01RjWXM9FLIpn MRScyRdeyG4WOWLBiXTzMmqd/8/cT5wseklUgG6QCzScWiI5SpX5dmxBxB1Z6IrEy9VYIY YcSi0P4XKaldb+1XCqyapZGHfUDqnm4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Y1UBDom+; spf=pass (imf24.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2163dc5155fso123848275ad.0 for ; Tue, 21 Jan 2025 21:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1737525565; x=1738130365; 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=MU55qMB62NlP1Hfg8Lf4TsS0i/+gjPtdvpdv0f7R4WY=; b=Y1UBDom+3SLSD7o0UVkGmdyn2X+wRsfRkk0pLbI9XzeC0NNPQPJFkYXNaLZiOMKf4t 2/nrNpXN9u1yEmK20srU2kKHZbO5S88WqMXtVZIi+zlbPzGoD9gLrshHBh0HW3Q5oPxl of0DS5Cz5wxq9gRr+pSNf353L0Klhn7nZ0MR4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737525565; x=1738130365; 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=MU55qMB62NlP1Hfg8Lf4TsS0i/+gjPtdvpdv0f7R4WY=; b=jaIcdU5GkusN8Ut1lKieEdMqmgD0lNP8MeNtvk3M4BTsQqbyZ0nx9LKyhGS87s0h0M A3jNiwiZ4Tkh2aYQbcsi8EJSOOK9L3w3XyFubSBOdKXyJOnQ3RGbpcMNs9TvuwfAeONr 4R1l7qjwFqaYF7zpZ+rq3TCLEJBmTzDipzsyzW6LV5eCcwGO7GUnzxlmSw4/d0jPH9L5 iIb9UAT3EtstfDf58feDanHVAxG9y5g1jIvFM4D+vETZbRls1oR/Y4vENWyPI5a9Puvi VG6UUD9hXYh4wnEtiVTwJY58bjaCW9gyxypJxYbkilo/R+NHq5vm9HJZ1tBwNJuUm7nA qvEA== X-Gm-Message-State: AOJu0YyQAVnlesA70UPhq8XjZSL2XiHKZdndx0sHRZbLcXvE5PBN7hB7 6pskU4bCwozDZ4NEBOHonetRrp9wjKSoK5sffotAuLe8evfQ14dn1Omi8T6MNQ== X-Gm-Gg: ASbGncts5uk82ymxlrYIMtXGdEHcDbJ2RvpTsW505mwupMcUbfPnk0h0ZQS+Cne1WC9 Hb7l6V00/LqtgummuJtUz/mHOHYClXK1uvdX/5flh2iHZbLc67dSLOpDFLzoy2krkTBLGiNN2eR C9MiXNjQfsAlqhAWqrwf+2FZk/PWQfRwBwDuMiKcxbgNo9RI2REZykztmsz/qcRO5OOsMdglleK 9Ej/iXqQm2MAUCIFYFh6+C9bXrFQSk3T3RP1VxTCGoWbZ+V6Luq1rN3h7nJURQuxjH/pUBF X-Google-Smtp-Source: AGHT+IHVvjN7ukzTgGkrLyv03/2Ys7IGx6CgvGp7QzNoO8SNF+YE8BGXBhQxnVlgYQWffGVAiCf6Ng== X-Received: by 2002:a05:6a20:3d8d:b0:1e0:f495:1bd9 with SMTP id adf61e73a8af0-1eb2144d37bmr33294873637.8.1737525564931; Tue, 21 Jan 2025 21:59:24 -0800 (PST) Received: from localhost ([2401:fa00:8f:203:2902:8f0f:12b3:c251]) by smtp.gmail.com with UTF8SMTPSA id 41be03b00d2f7-a9bdf0b7579sm9763985a12.73.2025.01.21.21.59.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jan 2025 21:59:24 -0800 (PST) From: Sergey Senozhatsky To: Andrew Morton , Minchan Kim Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: [PATCH 4/7] zram: permit reclaim in zstd custom allocator Date: Wed, 22 Jan 2025 14:57:42 +0900 Message-ID: <20250122055831.3341175-5-senozhatsky@chromium.org> X-Mailer: git-send-email 2.48.0.rc2.279.g1de40edade-goog In-Reply-To: <20250122055831.3341175-1-senozhatsky@chromium.org> References: <20250122055831.3341175-1-senozhatsky@chromium.org> MIME-Version: 1.0 X-Rspamd-Queue-Id: EEDC2180008 X-Stat-Signature: 93inn13aow7y6kp8nyizohwsb7jr1rgk X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1737525565-449558 X-HE-Meta: U2FsdGVkX1/V4Ib7urQikLaSqc5xRH5b9F414LooSRG7ed8uycvZkHLjc1rHVf2yZkh48rZjUSIjfUhMDYA0ZiTmzwge99+mHGwWmEcWmDmhnVUfdjM7Fi8zXPD8Ydc6dBot0QjigeG390FUNZv/Xw0vmKwcVWSQGZ7uS0u7bS9HkdeKDZ7R/FUE4yySc1kKnRAEomFNG+BLzbie2Ajz4M/Un2FKbPTZMnz+8a83qigOOucf7jyUaAABOLRWWGW2fCps/rBJ1jSH/Tl3M6WaPTECEIXW/3Y997Wh4+GatjlS42DHTi6DYLQDWEV2etQkyos8ZyTnJG5Ox3H6dYqkFqLImaE/zCSKquHJq8LEwMBr8TbFt8gZnz4sWxqeHAIgJBMkDhphIt0/SSrMvAnhigzfTr3aiwH0pw9Gx6Gvq7n+ilwPQz5IoYmMTmgNGT+e5Nw2XpUxl/2NEh3w6M8HJIWWCjZiS2fBo0wVDLCHB0VMwRqQuyNB+Df7k71C9nmMTAGIFvjL41WXLeV4WBtlcNmY+bbMLBCJK+eL/N4pnbapKQ9G/3xqcua0UDmjXHWl8Sdxfo/jtUNUhJzZ89Tkdlx5WxJGbkJgGyxFZhgXL3XfyXutXeCDKABfjeNz/JcxU3q1x7CDe4s+SvlNudN6O48Fp6EKs1yGKuZDcfS5NSOOPiNZsq+x/zaUvXzQU8/N+pIqyaTQ8DA0U2YiAqIRCiXu9ay2k1/zu/S815/veOdWwIQ4Q7ggqbPBu6ntgSLxIkzUJby8//kWaTsfXXS7j9VTECyD2B3eZaDJgXZT5R+gZ0ap22d3B6+LmICQTJiDouVII5A/CoBytj1xYWFy3k0mgV3kUOFDipeO7OjChRInnPQ9TgD3wY6ZNuPIq6WMVwDgLkuDRClz/k3R4IqsGRcOk2OQoA7puAqGixctFWwal2oo+fKmVVmbakhpt+eI7cSDtKO/w93g94lq0dy GxgLOSMl yi4czqz2lCnDRqzVegcoz8pDlwcmMTYF6lWCQuoFIRNAIXSJluRGViX3yl679jxGF+7Scra3T1nUyyDzvEKdy4ZMh4KaTRQdJsI709rpEOPAiXjFVfs+F+Zzbmf8mGnL3BSkBrSBGR7NzJQwZXwTVQWeYSeFMZbKqmcqFLQ6NtNyJnv0FsQK0lX/WHvzmQjUHP2C6IP5DcaU8X4nO/3Vikf1ptWD+LaNiQPMkQz6FMw+vHaGcjVr7kq7EsXFUPKbNYk8YVvcQH2DXUbHMZcNGJ8XlQ3t0SEb8/2oxm89wwC+U38Y0onIjt0YrZw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000093, 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)