From nobody Fri Jan 31 00:02:47 2025 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CDC91FF1C2 for ; Mon, 27 Jan 2025 07:30:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737963013; cv=none; b=WH52EVXmXqP9IhbkRrlZx495v/J8FZHnS1wHyomNohJiAvor0M3JpcJu7UcpeLwLhvbxVgtw7KT0DZEPboECELnH6oKL8vR4P7kJ91vStdEr2QIEsonbbBQkVpw81VOSP826nb8O4rX7PcFWdo1UqxxktZaIF7l9zI790KnfBmc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737963013; c=relaxed/simple; bh=Ej/13Gy59hq4pSeuXyYtdu8JOFvxFaLu/EaPO8MCcTs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TQ/4g4wK6Z/t1nC5XMm+9qRIKUpAvZyZ3OUO8HQqcja7brFJYR37nP8AUCElne/9bAr5qQFOtWjCQfYFfdutnd5jcpQZtmkuETuK01f+Z91ozTGLM1xrnXVKPKDtrJzbuAD1yChTn6DJ+JADgvcb4sHdL9D1IIsgdQ/0+7cm5bY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=ZBymykRS; arc=none smtp.client-ip=209.85.216.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="ZBymykRS" Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2f78a4ca5deso5385894a91.0 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=vger.kernel.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=ZBymykRSU6rvWFHJZumEXcLG/E1YUcPFaPCw+hmYefCBpT+Ypx2PEyDxzcATSHMKwy yWWFsgpWv6SZMkBpjwzl/Rpkw3ZrnLpVnAGrtDUxTLYb12KI+aPqphzxxBa3Jcs9FCqD JNH0P7PFHBmKfA+Y3hHB1Ebg5EaREHQy+LYMo= 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=XGGJ+RxTImvZmtGXCig0J//P9+OuIPyPJD3LMcLC5o0OVsu1Uqz0B1UAo8YWJopr2C ++a+OaUfjs5qim170NFZx65QteChUTH1kOieWR88jOF2pVgqgWHJInBi1DeaXPtEALMi Z69VqYbOMSinhEh8GzXl5Ry+RqE5L5gYtKqtOxE9uWMfcXNX3u5ekkdaXiiEou/QjqUG gpXRcYJttfaVyfkqY73Zr19NUWCPK5nXh7hCpItoO1XE8xLzshnR38tcHCfH1guhXw86 RfDcS+/NuNIf+jSW/EcVNGsY/tCPIzHq2aD33r7z+/O6lB1DA/KjNfAS6HG4PWTVRt0n icAA== X-Forwarded-Encrypted: i=1; AJvYcCUNhDGzSN0YuQ/MxZwrEpK9W3kxleSVSmTSEex/yK0yDr4rnRZcUXQVLcyOTTfQO8fwfrQ0zvkTY3f5KfQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxnbjP8XogozRWlEiGY+FARA//vAwMYPCaPwdUP6rUqh8d3iie0 nGxvjNF3XTw7HfZFEtsESevfxFKfQrDMYPv6gpCLeta45g3DhJmMRTC8ry6RYZhgi5MG6DuIWB8 = X-Gm-Gg: ASbGnctvivVutkJWl9aI0I9xsUVR0QbKQKiH4gY9GtNWZWM4yLYisrIc7eCUAHLGek6 JSmRxiXRTS5Zm7UuqJHFcxB4v6WG+A2OYu2mH/+TpkAh7+ZuCKQk+9M4K0Mht9cxY+ehAlajrAV fJ3OsiPwQmQ2wxk86UWeiTfnSRWu7PeIbyq6D9pkzFJIF0qDUZ6WxWWs1YFgb93dZ7Bqzz27SeL Uhpr2f/0VVV3PlCKw5DQQ21M4ki8UoFVEjxXvA0INy7LPXFbioDYDLcDpizAORb85QAKoXwtRgq SG7K+Ww= 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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_compre= ss() - * 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); =20 - return kvzalloc(size, __GFP_KSWAPD_RECLAIM | __GFP_NOWARN); + return kvzalloc(size, GFP_NOIO | __GFP_NOWARN); } =20 static void zstd_custom_free(void *opaque, void *address) --=20 2.48.1.262.g85cc9f2d1e-goog