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 56898E77188 for ; Tue, 14 Jan 2025 10:07:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE2A2280001; Tue, 14 Jan 2025 05:07:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D928A6B0089; Tue, 14 Jan 2025 05:07:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C31CF280001; Tue, 14 Jan 2025 05:07:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A42F66B0088 for ; Tue, 14 Jan 2025 05:07:30 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 51A6180858 for ; Tue, 14 Jan 2025 10:07:30 +0000 (UTC) X-FDA: 83005630260.19.2D5651E Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 64ED920005 for ; Tue, 14 Jan 2025 10:07:28 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=SRa47nka; spf=pass (imf03.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.172 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=pass (policy=quarantine) header.from=szeredi.hu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736849248; a=rsa-sha256; cv=none; b=QQ3uKkoRZ8qWOkvDxR41rMMGjn3FciY1bQw929+mrfUOmXPbZ4g9RUWc4H33ZjGHgDGrhY IwAOf3jlQc5XPrO0/99d8bx6AW1OnCu+CwZRwhLp94v/4TpTDwKyCvA11G1cbXEwbvmtUe BFRALM7h/N5hNaQq+5W8nmuVDK47xYU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=SRa47nka; spf=pass (imf03.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.172 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=pass (policy=quarantine) header.from=szeredi.hu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736849248; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0tU4xnHoOQ4ptkjuyhR+xNOthzAVEDHZG5olEh1NuX4=; b=15yzlDD32jOzRzq7KBOaajvVzq/X8LtgPrGMCzWqSOgaaPpzsfGIi4tHDyqxlv12gAJq0G Nw60a3J4As38AY/8GiNo69Xf7ShRjwcWWsaAZ+C/xdPR0GYBWiYynopOGuHzVmyEHGo4jv 9Kq4/sSeIm4yPMoa5uLh/ogm6jVVskk= Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-467a1ee7ff2so49957671cf.0 for ; Tue, 14 Jan 2025 02:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1736849247; x=1737454047; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0tU4xnHoOQ4ptkjuyhR+xNOthzAVEDHZG5olEh1NuX4=; b=SRa47nkaNR3ztFU5MMyMhcKzWyqbqN+vLNU3BNjywqFjFtpqMYEC/WGSLB9xYerxF3 10AArVaArOL0bahuAPvsHn/I6A7Mev+tb9DUA64TXUbSEF3vK7P0r95mmCWUdO39TKDd n9GeKRZV7JWtulHRPHFCDc/xpPL34u3EyXlMs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736849247; x=1737454047; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0tU4xnHoOQ4ptkjuyhR+xNOthzAVEDHZG5olEh1NuX4=; b=mJZY+qzfjoOVz8zXs2YSM8S2n1sgdg4v8woE44/4HZWBI9IIS2pNbig+cbHZzctpcW VaSSquCKODpCI3yvQtY1dP+hYTlPh1FqMlIAbmdfVWCEcpjqJAjAOLgfcmELXdrpDGGh khDbivhJJE051yRySbzFHW22+Hxxg2VahCOU1gXjbfdTL0WKXUw3UPiQooira2dAdxsk DnKkdAbK0GwYHyTd8SJRs/0G322q8kdKGvMnX0/PB51b6YyiMW06x4MNUlpsKFv761Th pA8LBvJTjYlsnsr+92lyM+xoZwRE8d/KzXQlOmR3tign/JMojzZmrU5YR6dRRLNrmPBa fRsQ== X-Forwarded-Encrypted: i=1; AJvYcCWk3yPW69wPor29IHqGlGv8ObBXjzZSn185RXFO2z1Hufy0B4/pJmLZq3i3px0bZzNYd5hKYh7vFw==@kvack.org X-Gm-Message-State: AOJu0YxCzrMydB4G2j6MCqAkvLTqcFeCLdPDi8jJRGX2lbsWPEe0CV0i TbQ5R/lCZr+ZlB61WaJNb6xN1XUrV3Tp5dWZv8oYLxfAhmvyR9OzEj0aSdCbuIPwRBtpVXft+qH 0ZfYH2P0jVNtIy4n1DzJtu1SGub1MqibwP0MinQ== X-Gm-Gg: ASbGnctVU3v2q7Ry8FWX9WRMENdQ8PSuqnOl97pejCtTr1/ECrYTg0+JoUNVAafXS+I ipluZBkWZ9NYdIsXoPw5lvxfD0NRN8GmRVXu0 X-Google-Smtp-Source: AGHT+IHM86AcpqAe+taIwtf4Bv/WyP95VBljCDSvtwFKlz4VZuwT4EO7BxYiZqXJP006KUCweFrn4ezF43sKGkn029I= X-Received: by 2002:ac8:5f91:0:b0:467:451b:eb99 with SMTP id d75a77b69052e-46c7101e8d9mr319619141cf.29.1736849247564; Tue, 14 Jan 2025 02:07:27 -0800 (PST) MIME-Version: 1.0 References: <791d4056-cac1-4477-a8e3-3a2392ed34db@redhat.com> <1fdc9d50-584c-45f4-9acd-3041d0b4b804@redhat.com> <54ebdef4205781d3351e4a38e5551046482dbba0.camel@kernel.org> <2848b566-3cae-4e89-916c-241508054402@redhat.com> <060f4540-6790-4fe2-a4a5-f65693058ebf@fastmail.fm> In-Reply-To: <060f4540-6790-4fe2-a4a5-f65693058ebf@fastmail.fm> From: Miklos Szeredi Date: Tue, 14 Jan 2025 11:07:16 +0100 X-Gm-Features: AbW1kvYDCYoxl7hbvd-9qDmaQUUlOh63oYsNN5iCyn7r6KKsxo4LXqtOm8tWtGY Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Bernd Schubert Cc: Jeff Layton , David Hildenbrand , Shakeel Butt , Joanne Koong , Zi Yan , linux-fsdevel@vger.kernel.org, jefflexu@linux.alibaba.com, josef@toxicpanda.com, linux-mm@kvack.org, kernel-team@meta.com, Matthew Wilcox , Oscar Salvador , Michal Hocko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 64ED920005 X-Stat-Signature: kgh5agntk47zobyz7qzfwc8dui5osgzu X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736849248-454881 X-HE-Meta: U2FsdGVkX1/A+SSpXB04iPpcLqHzlFb/Hp1EM/QeMvKZBwkCOiL4WHMRODefaNPtbDnh6xvfHvozbbsrCJUGE7TyqP9a3mz2iFyZb/lMhfT+eU7B48v6xo0zLrW37EJsDkUccTXcivq1+w8LcFqKfDJz4nAzPHNaJeXBwXLrTBCrDYANkFJ0qGgulpP2iKmVlSk27O6W/oabyn5MhUoLirqmW8eaJa+729P60mawl21fVLrWcQO/TxJPWqJGDRTVDNjeTv079GOS4uqr5pH+KAmlVlN31G9RtSzrhKStz+IzlfkIJvvYHjyYVAHZgHEHrusZr7+CVUnfgAOsK28cusl9pN4+9TieO+dUGRvKgcZ1ENSk0RZVWkNBBpfhzdLHCeDdCO13JfTnS8QDrwGO0RZVNl7i8rMe7XBvXAIxuA6a36WWqNStV4ZKHaohumzgfX5nMzLhu4gPNGyq4nNi0SX7G76eh9ijaoKXnfgIR89oZCWXggy/BWEapSXLTVCsrwXfLcngiSt7fJV9E5KfVP90WRrOuztEuOxpYp0Ou71Ihdx1+ZQZiQ/jUCENmQU4Xi3omLGty57lg/j1NZjde9OM6g2XvpE/GBgzBSS+iSrmDa8+F7ZyWp+c81/2tO7U4jOHuJSK2Gm+fJd/B65o2ukF9UXMUYrIQL+7u9ZKba0XHSfF0AzpFhruKpdwuqVqLNmvaKSrXGaFt/EQp2v0cFRjQ8NeqZlBCdKlpQlEWXP/qYlEKogvx9hWtcah1BjaLqKaPR8MTvGjFgu0Q9NA3FW5wPotXFloeOFIXTMWW+MPpXagSIvvkRsY7oD1vuXzOzOlSG+opL6kDzrhXMGMFwpgjYp3HoFAQKP7XHSoVR0KD6fJ9ChtSfrr3LOWOwrg8/VoxO4N2T8IN+H8wBs1lKjEhjlAfmzRi5FmA7NXaI/4rHbjIIDnku6IbR7NmFJ6HAWRiMOkpdiWPNKuvXM gZJVnE0F 2s2OqDA6U8R6mcs9TSrJlyUvWU9w5W+/QT+2DmZz9vqcMShjDB2c6BT/rmYLupZRJOZOAjXgS3UEg6M94/VAwNnVXAsvzuUWDL4k0n4r2gzsm4sdE9Scqv+wMnF0j7sccyeddiE40bjVhA8NyNOOrc0wBiYoV7Kl90XkSf8BuBY2+nbDSnReAWAJKkuGql1nUuvjEjbMOuZ08dnm/2DTRGOD2jzNJL2TsLSnkh/ZFOk/ZbiOoVtsf0sn4+Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 14 Jan 2025 at 10:55, Bernd Schubert wrote: > > > > On 1/14/25 10:40, Miklos Szeredi wrote: > > On Tue, 14 Jan 2025 at 09:38, Miklos Szeredi wrote: > > > >> Maybe an explicit callback from the migration code to the filesystem > >> would work. I.e. move the complexity of dealing with migration for > >> problematic filesystems (netfs/fuse) to the filesystem itself. I'm > >> not sure how this would actually look, as I'm unfamiliar with the > >> details of page migration, but I guess it shouldn't be too difficult > >> to implement for fuse at least. > > > > Thinking a bit... > > > > 1) reading pages > > > > Pages are allocated (PG_locked set, PG_uptodate cleared) and passed to > > ->readpages(), which may make the pages uptodate asynchronously. If a > > page is unlocked but not set uptodate, then caller is supposed to > > retry the reading, at least that's how I interpret > > filemap_get_pages(). This means that it's fine to migrate the page > > before it's actually filled with data, since the caller will retry. > > > > It also means that it would be sufficient to allocate the page itself > > just before filling it in, if there was a mechanism to keep track of > > these "not yet filled" pages. But that probably off topic. > > With /dev/fuse buffer copies should be easy - just allocate the page > on buffer copy, control is in libfuse. I think the issue is with generic page cache code, which currently relies on the PG_locked flag on the allocated but not yet filled page. If the generic code would be able to keep track of "under construction" ranges without relying on an allocated page, then the filesystem could allocate the page just before copying the data, insert the page into the cache mark the relevant portion of the file uptodate. > With splice you really need > a page state. It's not possible to splice a not-uptodate page. > I wrote this before already - what is the advantage of a tmp page copy > over /dev/fuse buffer copy? I.e. I wonder if we need splice at all here. Splice seems a dead end, but we probably need to continue supporting it for a while for backward compatibility. Thanks, Miklos