From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pz2-f42.google.com (mail-pz2-f42.google.com [74.125.228.42]) (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 F204D4E73A9 for ; Mon, 28 Sep 2026 15:19:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.228.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790608786; cv=none; b=rM+H4D5o81UeLG12Fu6qdPd5M/McjxwBYwvB7axOY1xiYY8ZoWOyQZQr7ACYKz3OWeg2Cxd/HRGLJhFvGOlZuo8dUd/diPepV6KLGtRG8kvbCJZLHIVNku9sxFlDGDg25D9/M48ZOuE9h4tX/fkYQVYmtJCw4ww7jNgUMjbDeLY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790608786; c=relaxed/simple; bh=qFYBnXNYmhhsHxNx2COBADOmOdhhnVq5vY9GOOKIOJ8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YFk2FkenPicSfvivC0XAivf7YFaUJAjgUgLJgADKXn+6IqNv/QllTTSN1BSk8vX4OPVvoJVsJKca9qrD6AKFR2qp96ST8td+TWNM8l111+7coLCbV7dLkp7kxWW+Z4gVGJLD5L9eJ1eJeTY5x8BxEjVbD1T1xDzTy7Vur1jptr0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Mcv3pLez; arc=none smtp.client-ip=74.125.228.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Mcv3pLez" Received: by mail-pz2-f42.google.com with SMTP id 41be03b00d2f7-cc4c3304784so1287635a12.3 for ; Mon, 28 Sep 2026 08:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790608784; x=1791213584; 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:content-type; bh=h2+B+TCtU6LhjPX3KEHp5ZhDWyuT2oD8RctAdhdkStc=; b=Mcv3pLezAFyOR8F75xJ+N1J+sl5iObide+S4U96tO+DgnijX5Dmv30l2bJPwN1+1O/ aDuzJbHgkNaz0lfw14o/KwYbNznQUu7xfoxAvpVI93mnAYbKzBCw1eNQDku74CY+HfZZ PW4KSnS4CPVrTmns0V/auUXCoQVjg+oAMiGULt1W0MA2xWn7cLmEQSDCHD855uvtV9X3 gmimRXAP+b8P5tg4Y1swbLZRAvkFTJbDFLJEEFCREXen1/VjjyUloPUHnLfUPQXAU4AV 74V9RqUw2P+Fwuuwm6XSQxgYih2pRhfqAVjfgoKGuEwYAv6/0uviPGmqijunI+77tcYn bP3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790608784; x=1791213584; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=h2+B+TCtU6LhjPX3KEHp5ZhDWyuT2oD8RctAdhdkStc=; b=ga+OC3k5HvW/csSoA+Lvlwgk7d6wF8aQtqDl8qYFBY3Kdj6OW7NiiZRLvMq6WuSQhj U+RT6sgs3KJRmmIch12kb2ziLczenJ8dqAIxszT4q7F09ZJkwtL0uO7lF+rie7/LMmQh Hc1S2fSGvK9LZj5BkrYePMk4CY8ssBlxJj5Tnm0nfJrbSTPHHMVt87ho17YKVjBVR34P pNC8aXvI4pCbYr9fiNqxqIZuDTZkpKHKF1TVXn4407pTDz+EIIlw5615LLjCOJ+5zfYN PLZlX2lawFH6LByCNPmTh8lkUR/8zQ7QfZJP8UqK6tL90GRXA71MjghukaJyCzUOwJMF LT6Q== X-Forwarded-Encrypted: i=1; AKwUvByOncL6E7S47ZZSdrmIrbREZSLcRYQQI2jJfhvLJhTZqx43zZ8B9/UkdmH+7ev8zPKGUvggHWGY1he9l5Y=@vger.kernel.org X-Gm-Message-State: AFq9FYJrRszhrydHf73q21eUTNnV2Oskb957rOZFh11wFd7Swv/fUB0d A5hSv43eb5WJzcWoMLbX615GzZZeAMWg+72HHt1VJDdE2qyeFy1L0NY6 X-Gm-Gg: AYBFou20LcbwO95mZleRBC8vUBI4K1Lxy1mSsj5r8o1m2BvTr6mxi47F5Wx6FLeWgtJ Uo6eXI1m+tBuC9nVVVJ/hiiwa8Dnf+2KJZ8wZDxNiAB613A7w5YCCJN6KdiI8TNKzb8/GvGvOni LZGdmGUlpXZS9ocAtuSo9R02M9/1iQgvOYbSLsbs+ZlxdWVpNUdtHE3YNt6t1uF0q8TpJMj1gAF Ncu17049HiXEM9g3xPKbqsdBaP1hdx30NIYZaE4ijAl2bGx2068qPkbT5c5At8gvKaI7t1h2h8m Ily2QcCEYqWbRf2wVY+TPglxzHKnC18/RvkJsCl2pcajs24FvJPwm5ovuUrEAVPP7/DA3Lgh7IL IchPnCAum/renGMbSAKihTuuirCxHXreMy7Gk1a6tFU3Z+aM5VbERCpPgE1tH50oYNpgUYJbaSL qRnxcC9DUYYjNLltD5Zp46C7UeZIq13rfNOhGMqh9H/Dgin2HZd95FTKgWer+lZSyxvFmyLMTnC z7JlTQaeuIkJtwdAuUDeREfzWo4E/j2i2qQ+7X2A0PrsiPfW9p93WAEOhs726xr9c0v3QhvOIqx v+PXhWQCrRhk8G4Fk81z5qwweoMthlXZgRup5xm7/kztVcbSLhpO/ohn3Os= X-Received: by 2002:a17:90b:3908:b0:3a0:c20b:2fdf with SMTP id 98e67ed59e1d1-3a0c20b3132mr6450444a91.17.1790608784281; Mon, 28 Sep 2026 08:19:44 -0700 (PDT) Received: from spider.bream-herring.ts.net ([103.6.151.236]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3a0b9feddd0sm7247965a91.2.2026.09.28.08.19.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2026 08:19:43 -0700 (PDT) From: Matthias Goergens To: Christoph Hellwig Cc: Andrew Morton , Chris Li , Kairui Song , Johannes Weiner , David Hildenbrand , Michal Hocko , Shakeel Butt , Kemeng Shi , Nhat Pham , Yosry Ahmed , Youngjun Park , Baoquan He , Barry Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-api@vger.kernel.org, Alejandro Colomar , linux-man@vger.kernel.org, Karel Zak , util-linux@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, "Rafael J . Wysocki" , Pavel Machek , Catalin Marinas , Will Deacon , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Shuah Khan , linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH v2 0/4] mm/swap: reserve swap areas for deliberate offload Date: Mon, 28 Sep 2026 23:19:34 +0800 Message-ID: <20260928151934.2686418-1-matthias.goergens@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: <20260926045517.3458413-1-matthias.goergens@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Christoph, > Either way block devices must be safe to be called from paging paths, > not just for swap but also for file system based paging. So this is > a bug in the implementation, and not something worked around in the > swap code. Agreed that a backend used for paging has to make progress under pressure, and the zvol example was a poor lead. The series isn't meant to excuse a backend that can deadlock; that would still be a bug to fix in the backend. What I'm after is different: backends that are correct but need memory to accept a write, where the better policy is to use them for cold-page offload when memory isn't tight and keep pressure reclaim on areas that don't need to allocate. Two in-tree examples: zram allocates on writes and fails with -ENOMEM, with no fallback, while its logical size still shows free slots; and filesystem swapfiles must give up copy-on-write, checksums and compression today, because swap writes bypass the filesystem. I'll make that the case for v3 instead. Thanks, Matthias