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 AE6C9E77188 for ; Tue, 14 Jan 2025 09:40:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1713B280002; Tue, 14 Jan 2025 04:40:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 12150280001; Tue, 14 Jan 2025 04:40:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2B1A280002; Tue, 14 Jan 2025 04:40:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D3F9E280001 for ; Tue, 14 Jan 2025 04:40:31 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 001B5A0802 for ; Tue, 14 Jan 2025 09:40:30 +0000 (UTC) X-FDA: 83005562220.02.AF739BD Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf22.hostedemail.com (Postfix) with ESMTP id 1C030C000F for ; Tue, 14 Jan 2025 09:40:28 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=TcxeiiHR; spf=pass (imf22.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.178 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=1736847629; 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=HgPy2eorjQtqOTgVzB2y5cAsY+IvT0FtA9XMxPuPMDA=; b=Kckt0nWkux9+97jRWYYfg4hW9ZF2CO7KBnJAsNlPo48j0F/8dS2J/wcOmaJBGneH18I/P0 ksOONJoOaugrO9OSLFPmBhKXCckwNorXV4FC9iMXcQHs2V2m1tIIG9UOJfWTaci0l/3rbs dx6VvovXvh2QtJ7EyzR8QEW6ruVDbgI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736847629; a=rsa-sha256; cv=none; b=PkPRVb01gtEKlffojvcABEN0YKmiXDfxJhVn9dQ26EKkxLwLSPRLtIOYzX6Jo8qVjpmduo wynuJv9ql0HkvhrXotvezdAdSeoKc2PrhN8s2b1k2US5s8QNtP+zyI68iHoWloQ2bHvxIo /UKznO6FYoUF36IJTu1I/oWmDpePA3I= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b=TcxeiiHR; spf=pass (imf22.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.178 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=pass (policy=quarantine) header.from=szeredi.hu Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-467a17055e6so63019921cf.3 for ; Tue, 14 Jan 2025 01:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1736847628; x=1737452428; 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=HgPy2eorjQtqOTgVzB2y5cAsY+IvT0FtA9XMxPuPMDA=; b=TcxeiiHRgL8ueA8DcLqACsHfvLBxgl7JjPmeYKW/TU5KAoTsyyeJlpRQ943FF7btSy uTGs51Fh5km250ZCxBVEHK0lh+V29PCcFAXao8rmv+MMr0Eg7CnQoK3rSIiOUDrsbM8Z KCMjburtTDoau/PiuDbp1ggdHJhN1FlGrnl7k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736847628; x=1737452428; 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=HgPy2eorjQtqOTgVzB2y5cAsY+IvT0FtA9XMxPuPMDA=; b=a3C2QD0IdZ95DC7d3ylvm4S7aX4g04ld4pgVDc2hNN+R94+z9aiXU4TFZBmX0PptBT Sq+IcXcL+t6X1uaHVdhZRyQvfpux4qgQncubYHBW3ipRwS9WwOl0s9KiK/NDPA/wf46s 1n/85m+/FnLHa8XO71NxdqYlub494X3eabnjKTnNN/AkYK0jbiKv6CxgjMi1+AUU+9xb EtyRhwKmBp3MaWxpVhFO8KXOEVXeoFVg/sokufsTyGU2T+UMj67fp7we2HkNdZ5AzNwN yAaEKE3fmEw+aiwdDWRMExjtO0ckyZ3ZXZJTuPhxrWQDzE1yILRZCgWtMLXxAkQnpOQL RKpQ== X-Forwarded-Encrypted: i=1; AJvYcCUWPAgkdR9I4h9Gs3vBXleOZJsnp2l17DoNRx2sSX4ZY3fCn9qFiwZOB9e5a6i2qJ8exXKRvt5ysA==@kvack.org X-Gm-Message-State: AOJu0YzOSAjtWHztObt7TYB+N1PBa7H5ychq9DZOcAJ5ONb2sEnTk4YM 9JgjyzcH7YlavI32XmfCwxcM6OVosMkSFSub5lqk1+BwMlYoKqfSeedqYXt7RhccdlhUdfG7Drj /tdmroS/38ThiWTvcI4dDlUz2scO5TpuM9KNdrQ== X-Gm-Gg: ASbGncvbnLTjiPQC//jnAL/1EzS3qYECDaXJeEQwCeePqGz0KgdKZfpZ+9WEoN+GpqH oWDqeGIWSG7r+nJAEorzBS7gaR/CtIkQQ1ZPm X-Google-Smtp-Source: AGHT+IH5zcZYV4uugUlC0KgfwH0v4ZvazwCDkLcLzwd/+LyEAh5KxIisX+gUXKeRn1fXcoK5aOWBXn/ZrSX1cT3C4M0= X-Received: by 2002:ac8:7c4e:0:b0:466:ac8d:7341 with SMTP id d75a77b69052e-46c710841e4mr356199921cf.35.1736847627940; Tue, 14 Jan 2025 01:40: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> In-Reply-To: From: Miklos Szeredi Date: Tue, 14 Jan 2025 10:40:17 +0100 X-Gm-Features: AbW1kvYXIdAjEYEuwiuhLrszud5yTv1k-6o5wyMwr9_6HvXpRPUCw9p-BVpd0Eg Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Jeff Layton Cc: David Hildenbrand , Shakeel Butt , Joanne Koong , Bernd Schubert , 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-Server: rspam10 X-Rspamd-Queue-Id: 1C030C000F X-Stat-Signature: pn5c6o3jxpxof5p3mf7wnpnkkrqwr6ou X-Rspam-User: X-HE-Tag: 1736847628-465239 X-HE-Meta: U2FsdGVkX18ErwYMhZfeFNyTrBW90BnkcZNQykgjeflgi2nE+C8FsGHJaBsMKVQqoOI80EHsMSJGN0eiZahfDr+G1qP737REwdmLw80y0xbSy2GUB9yfrvzufjw/ll6jPb13YwaIeK+BlCu47i88iK4mwifKB4rlxQNo+3EXw8dKXP8/xW64f5KA9QaN/Y8eb/yW9g0MdSWTwYrKwD3FCgQ+1zfDyP6iDIhU1af+lr7gO0z3l5qfl/hmqLPQayLiseEUAnnCTuRa6doCqGk1Yh13jC12tAExAgF8BO538vSM6hokFI6BD50aOkfp0lBUn2Kk4j5DIV40YAa3gELAQ1tFLbAQsYgQTuOGFWUEF00LxWMx8bUCLkQqOPmjG+AH+WYPPAGhSwF7psaiqaH5cizu5s5oDc4JS9Q2YjWM/8wU/JnrTo5/j6reVjXOWeNlU6bn34Gael8gFwQ3uAF5Z16VJ9bbboIUBUtyvGhem0hxl4qEZEcQ3OICWoQ3jQec6GHuK1NI4zY5Apo8Q7P64dLpmE7rZrSGmDBX33jt/OUVoDJ606gGA5Gmu2nxAHlBtqDR51XbY2ghqgnZcoarbHUfyKoj2WtwlYfy7aqSyOa0gy0AyDkNeVV4V2rHU9/QbitB/owbEToY22/5DTB3JFa/GjFgyHUxO+pmD4tSiKSWu18xESSnrexOelqb6/gV4zg4R4/jT1aikXjOeSiOH0ZU9XEvu9qvjJrsAmrC3HeNewQTXAWroKdod0WNCxsqk0L+34sVjDpGqQrvojRXVhO/AOLofRkPMozIubEsNLAa/mtjricFZBWdEBa6pWM2Ppq4+EBlEFMHmokylp7xloHVzzsnW4s46ZFtBJAV4hiP2eoMOPbACMw1Rvlo49KGHp6wMfLcNSynZzcdIaefa6qovzreDingS+Te/e0Vmj9QmHiKAmHd9Zi4A0pyme1amStzFKknd2mJdN78V6a oRkWj40S 9XX89QtSUK93+xTVCtfRRnide4LPGIx294OusUDMZw20A0aw6nc3FK+xufyMocTDEwaM/5+5aM1Nf16oM4xANPDBueSUkkC1ecNqk01uuytYXDMgydB0RjzQ7QKdmNVLaJHfy95aIy/Ivohh8ABhyV5H3i/sSrd1CU33zkmY0ggmEmPOoJU58KsBCHvi3QmTm75gAr26Fp3UrZnZon4/2Ft/KrWI4KAVhx206zZFD5FhKZr1KD/orrjT+AA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001199, 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 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. 2) writing pages When the page isn't actually being copied, the writeback could be cancelled and the page redirtied. At which point it's fine to migrate it. The problem is with pages that are spliced from /dev/fuse and control over when it's being accessed is lost. Note: this is not actually done right now on cached pages, since writeback always copies to temp pages. So we can continue to do that when doing a splice and not risk any performance regressions. Am I missing something? Thanks, Miklos