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 438EDE77188 for ; Tue, 14 Jan 2025 20:51:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D766A280003; Tue, 14 Jan 2025 15:51:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D26D9280002; Tue, 14 Jan 2025 15:51:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC6C9280003; Tue, 14 Jan 2025 15:51:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9FD45280002 for ; Tue, 14 Jan 2025 15:51:47 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 505C7160CC7 for ; Tue, 14 Jan 2025 20:51:47 +0000 (UTC) X-FDA: 83007253854.11.F2B9139 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf09.hostedemail.com (Postfix) with ESMTP id 6A9F3140007 for ; Tue, 14 Jan 2025 20:51:45 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="fPcy/6n3"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736887905; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yI8ELS3CrLfvjr9n1M8dG4jWDZQ1aT/IxMYt+noPB1M=; b=mEVFHBVLW7a/FKj63yGkSr5o1rdEmlumJUzOVvgaCPO0KsklaB5ynKncRnkQ+eQu019W9h h8Xz2n0NouSFMSMXiTZtTUjoP4IVu4Azp70VCt4Ap7P6EcHV9QohgBNd1r2PBIvU8Z99KB 0vzbM3qSuvmLVYc/AsDKUYL9x+1nN6Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736887905; a=rsa-sha256; cv=none; b=4+E0hFaxTvufen0lZ4H7lhKEyD/f+y6JglaUQYcqxmYy5Tg2/1SeWZMh2ZbNFWNxQ43k/0 44TQyl8QkpkFTMCdHKLq2q6Atm2umKtNdH+zoAtUNhVkJFweVjcY1xTcWRfH1KJftjxOK6 Vck30jNeWBofmT9rIYsagxN9mUxxtVc= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="fPcy/6n3"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-467a8d2d7f1so47754881cf.1 for ; Tue, 14 Jan 2025 12:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736887904; x=1737492704; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yI8ELS3CrLfvjr9n1M8dG4jWDZQ1aT/IxMYt+noPB1M=; b=fPcy/6n3gWC/87Eid6CJTm1xNAgyzQMOgksxeoKzC3osQgEi8O6HqdkdwPCqjwuQ9M wH4nUq9S2pr4nA7JHthfPHAINu9KDdr0nArlLBuIukPlqwnlZUsfyitL0yO+JncHDbTt dJ3jmcUxZCu8nyM3xDNjo3kEGv3ob090p4Z2cwrBkM/U1UVglVOaZU9NgI+D9jGWY4m0 oAcuIvvJRDVnIjLRrKvDpKKz22GH6niwF9v+Iu0KnyEfuEUCLqX/xEmb+wftMFTScMd7 vndApt0AMdkH9QGX/xRtH7Vqefpw41yAlS3o9aipCpVEWpZUP1XQEgeWhUjfNDVCHZD+ od4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736887904; x=1737492704; h=content-transfer-encoding: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=yI8ELS3CrLfvjr9n1M8dG4jWDZQ1aT/IxMYt+noPB1M=; b=gtMAPunvgJBsf515mF5YkwY4Lg9QCXbBs67BpOOsvLOCOzwq44BZFkHvQsCy8oWsSn lORYLo1qEyogEf9ggF1YDcHOKJE0/jeSYIXQLWzjr3uJ+IIgOQpD3NF3eEcY2VcqxfJT 0GuPEs/6CWskm7GbkL14FWPfoIPKoEdvmdViB6971Zjx27OjGbtAYBTaTVAzhoA2IJUJ nJbHZP0tFLCGGC3D/G5JfvzD9NfdwXZdDvEVZtE3HfjhuZpW7HQ29BqunozWSryleXTl BMCJml8V3yP7bZmK6k741zV/KtP+bWBQebLH8Q4rmtA8tOYr/T2TLA98kvTE2MjMd+H5 SlnQ== X-Forwarded-Encrypted: i=1; AJvYcCXQG229iR3bKp+jaNI1Dwfr6LwL5oNFp7lHPWuth9bsz6RsklURPjmO1vlnJeyGRMupH1hVaJWm/Q==@kvack.org X-Gm-Message-State: AOJu0YwWPRhVwTvFlNiuD/05220/9tV7/4HI98xbClM9+S6oXlcSA/mI phk+yiyFNp8lpLHFaoe1FlYU1mV8TFR8icbWiDhKdHAFy6xm1unvu7aDqaE+bdMzOalWRhp/A6v gDy3vmrLpfk+cROWKOYFXsF3xLZs= X-Gm-Gg: ASbGnctcTPwV2phX27rrFoxNjIzclQJmh+2k27dFZmNgS1FArwrtFf0p1bgiaIrsJOC TRdLnnVcYpWrxqgv95Q/DDJa2U0nDBmHYtfGu1oc= X-Google-Smtp-Source: AGHT+IGlSQh0zQseImd09NZxrO5yO6mkSZv2LQugburHsunToKK2iHUYzz0o/WdE2zNxSjmv93TYm0E0geCjgi0AGIQ= X-Received: by 2002:a05:622a:81cb:b0:46c:7197:58d1 with SMTP id d75a77b69052e-46c71975911mr355365991cf.13.1736887904449; Tue, 14 Jan 2025 12:51:44 -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: From: Joanne Koong Date: Tue, 14 Jan 2025 12:51:32 -0800 X-Gm-Features: AbW1kvaGat4QtPsnY-5ZYlWa2hyF9YwThPdM7CmUWonPOgPdCtmGyee-hOXHTTw Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Miklos Szeredi Cc: Bernd Schubert , Jeff Layton , David Hildenbrand , Shakeel Butt , 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" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9p3prsifbfsc6yx166pzohtqdon5hpk1 X-Rspamd-Queue-Id: 6A9F3140007 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736887905-263598 X-HE-Meta: U2FsdGVkX1+bKMr1iGPN1tOYdfqz+7cuMnt5HGt15qQWZ11j8kjvZiHeeBM9VpDzg56GP9i1BF1RmM9szV36YQvXr8MnfD14TwnvFEjRiJ8AqjZ0C3bVLynnk9T61SzS9RT4+IlNJVakV8gRLbgD+0Jl4gres2bdFIar9zNQjKPZlb6yESLITXDg/QH+9TSO90nohz/IeS1j9/ne+s5znQjh6S9FGh/yFpS3QRQNxYq24RFYWwQmLRMYYlr1CyyfREEJuwhrnFdBo2JIODFI+ViuvkA7laDBjMrNY8H14PAiV+baSLKXl7N+hTtfF6OxYOnwSX4HBiOb2pTkF50YU+InGE9fxPn5Vwbfx8taIRnFLNOH3BFHE8G3MHkFTZxhYilYyOeJvr6ZybI+gbfnaRX3gbzlaWpoxosM9EglYC2lFDwIX82xSLGQqsswuxl9W74zhlqQt0bIqsz+XDnJEAAD94DQorf9UmqW/yCnxSKyXLRjNoqoD8oltg8BzoZYLpG8i8P1kDh8MA2mDNEXu6GB+GUl3toduPM+95ZSyBFvUTyAjtOS2SzrRE7NHSnYuqQZaHKWvrqIwJUOLC6kbviv8E+dzjiekECCw6dxCLICpH8VqIFj9wDoG4vIXs3QkNfMcSDPkaCvjPXacrSEZg7AZLjHtMO0p5+vvvwolddWmPF4yLxHn0eHqhHHvtq3p23inv1pc5QvqPDY1cI5PZ6642SXC6HluxEVH1+r9CW2VE5aciEXXaJYKk1i6zD6Fq1lLQeTC6hKUZ2PE09OKCs3kdaxTriCrlSk+sVX+xsDXRT/cPbbT09wpRDeKO1lTe2fXBoQ8NU5zrksxcPRWSLz7zui0Ydy0L2ENfQbRWllw9NJQuLuSqQKHaNqOCCPkVz4QnV7mpfgMZeYuQBwlAasysgMqSMY2I5O5FrWdimQ97PQ/Lv3j44vrXEkMW7wKxFNp/bPZgOYd1uk/zH JdRxJQLy U1ts3aj9xMxuPTb9qG9xzdvbbhW1/I2tBpzn9IsjTdnixDHAWUMeCVi1ikDu8eOKoaS115qCDDbiyDQsSn4FKVTUbX5FrPxsPiHCwp/YASSuKEr8VsigMnMxFvv+lHaxKBbcHOU2glJL9gAMgIjTPrGDj+BUyICHzNpxZN4QUXaRvdeuANXBCi9K36neohYToCFapNoyDwxB1SzUAYdmgWePjvfW3C2J8+9HJ4AhdJS/BQYsCUpZYW9nSpCXDvBgwHuKBIwLyLo4CBnONhObtZCvx6kK0Unqj/31mxvIUKcnI3KnQh8qpN0dUxyWIqjGRAE5bQNCxx7Flw8KkH8Aeoh/Z1h6aCktWKbHHNIiDtJ2zZsPBAPOzv/laow== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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, Jan 14, 2025 at 2:07=E2=80=AFAM Miklos Szeredi = wrote: > > 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 wrot= e: > > > > > >> 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 t= o > > > ->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. For the splice case, could we do something like this or is this too invasiv= e?: * in mm, add a flag that marks a page as either being in migration or temporarily blocking migration * in splice, when we have to access the page in the pipe buffer, check if that flag is set and wait for the migration to complete before proceeding * in splice, set that flag while it's accessing the page, which will only temporarily block migration (eg for the duration of the memcpy) I guess this is basically what the page lock is for, but with less overhead= ? I need to look more at the splice code to see how it works, but something like this would allow us to cancel writeback on spliced pages that have already been sent to userspace if the request is taking too long, and migration would never get stalled. Though I guess the flag would be pretty specific only to the migration use case, which might be a waste of a bit. Thanks, Joanne > > Thanks, > Miklos