From nobody Fri Dec 19 21:54:34 2025 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 C6B131C07CB for ; Wed, 22 Jan 2025 05:59:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737525567; cv=none; b=EKrnR2yT1YvTm7d+KzkeD41pXaMjJrOv9X9+OfzdCMZJf4hPeaLRjYvg2eW2H2bxmqDtq+lwSgTgBkj+fL5Om5vqJL1B3izLkiuXMMZZmomkFK5hJzCIIkpCA6vpEit1PfvyyNiUXeBGsMsyE0VfYz3/ztaQVjvY6bUDkvCTODA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737525567; c=relaxed/simple; bh=rCEbEkeSlyFPjPT0SyooPaVCaIPqGlAbHWVgKAX9DWE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TKlQZWXhibAcHn2u9lvTQwZ3XVHM3570z/KbxObzXerxS2O1QGOK9MlMlKW1SY9AhxlkJKjLhcwsEHNphfViDM8/oNOR0z2wsRndOtn8VVFutcNQobBmOR7MDCXDOQnxkGUuomoJxnH0V8l0197bOvZRt5k5BSYAPc9OXuGlCxg= 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=IpE4CXL0; arc=none smtp.client-ip=209.85.214.177 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="IpE4CXL0" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2164b662090so119224875ad.1 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=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=MU55qMB62NlP1Hfg8Lf4TsS0i/+gjPtdvpdv0f7R4WY=; b=IpE4CXL0Q8mPlB8B7NP28oFosREKMUCNzsicJ6dhmMwSI6DimLaKIOd1W28c0WYgaM dLIF1z1P9bai5SBmS/oVcPVSHwNqsuHw+AnXoTYXg0DIrXX6Hi7wjrQl+q/rJ5pXXl02 I40gHlALBh02lsWtiZhSZdWWYV0mrBnGWsGxM= 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=NbKcXdCZACs/deQIAEpwd3rOxwi0QQKPs4BRMKx9AIeoRUGwIfK5nM07dqgAUCNV8O Xq+GyY8UzavISJjlrJg4QZmtCiW6/PZS+wEzscoQ4TWpykcgq+rmmwOn2OZS/fpts+5R d4ZRbTmnN4gbkIIf6Sz+bNHYlD8BLxrBG7OHyicQEihLeQHG4e5if44V6h5aotg/bUUD LDEQhGOslVAgAwY4ATk4BOHUkswMBHy9JqE+38HeDzb0r5qqODWSJVKgj7YMQyHljO7Z 9XbO0dknXAy5Zl/Bwyh7/3WE0ihoxUL72m/88EXiWVclAD3OPVYMWILbtp/pQBgVYFVN QkXA== X-Forwarded-Encrypted: i=1; AJvYcCX+rZZBUWtMWBdcjCXEuU73z1o6oBb7Eo8tpWP2y+3545VCtZgD1Q2tg/OXsW1eg+1zZ9nAeNqgFmtIC+8=@vger.kernel.org X-Gm-Message-State: AOJu0YyN8cmwFm8or2A+OHn+E4xWg3JsElOVCyW21VWLp7Nl4zNuYH3G 3x7eZ7W/FIIim8gni3xRxB6gmgU2Bfqu+n73CyfN9jDRFB+J5CzNXOet4YsYwA== X-Gm-Gg: ASbGncthYyiPJt29olP9gD7dC1dL7SEzvwDg4HDZaLa93NPAsv0eP6YMMcFItGTPvFv zV6+bt/Q3UHQVMO3SWqohdZdtwc8K9QIoBqPP+yWGQrpcV2HrUrQS6QZVOaXiTbSmzc8qNjG5e7 1aPWm62qDel4MOzX9lce6wJuOKf/yG8x3vVwWuDKSuDKduvd14wnDkj95/O7KVkFPkcP1+6GK8a vl9M93drB4GT7vSBwJIol4jL3D0ziEtZ1du2VSrnZfd9Cet8UAIwyPoxSRx1ttyKHHzSIWG 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> 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.0.rc2.279.g1de40edade-goog