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 5968BE7718B for ; Mon, 23 Dec 2024 19:00:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 776E36B007B; Mon, 23 Dec 2024 14:00:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 700916B0082; Mon, 23 Dec 2024 14:00:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57A7D6B0083; Mon, 23 Dec 2024 14:00:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 39B416B007B for ; Mon, 23 Dec 2024 14:00:15 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E571A14106F for ; Mon, 23 Dec 2024 19:00:14 +0000 (UTC) X-FDA: 82927137678.07.7804803 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf17.hostedemail.com (Postfix) with ESMTP id EA0C34000C for ; Mon, 23 Dec 2024 18:59:43 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=X3EIqtYl; spf=pass (imf17.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734980383; 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=Dhu35mDIb/3A2ITYiT2TdbY19VVUfLsBSSpE3vJF3ww=; b=JfqMA6NwJfWnrsWPymUDq3toQZSao71NPCpNXyaLxIh+LURrwh4RfjZicQ5AKF9gNh581O uoajNqv67a/OxjQ/D1eNSN/fQHq88LLQAubVpr27TKkx4ozw6GzIivXe1yT8z5tH+wfYzl xMcN5JB045m8Rvx/YP/9mNkGDg6A2Q0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=X3EIqtYl; spf=pass (imf17.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734980384; a=rsa-sha256; cv=none; b=lb5Zlu0JQWxTHI0DNtjnRdsPTuShpqt6ZzTDG6/PBebeqrkPX4+u0aapyQiPVxObB9o7nW ZHfU6cHQA5x0BFcbE06uhETBTPqLdQxVOrwguL5iFYAAnN/Wwfjnrg1knyIfTWVPlLJcc6 hkokzKd1plRZRFiQWw7zgUkma0FLc5I= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-467a6ecaa54so32661211cf.0 for ; Mon, 23 Dec 2024 11:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734980412; x=1735585212; 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=Dhu35mDIb/3A2ITYiT2TdbY19VVUfLsBSSpE3vJF3ww=; b=X3EIqtYlpQE50hkQry0C/3Lj2PfJEZHKHZ5OK5hbOqqI2ECbUNBJM9MB7wp0YN65ub aADPv+guQOtsmhSBucUKNm0lJTpyfKdXFjTZmVSu2WIXVVw83ahpwSgGH7t2UdfFLUZY xwoE9ZicgFjPOrYpyw2eOfRDM0lkeKIkoOQwAiaAAmAla5Xuua5VMeqHC6guC7gGb3X7 SW78Asr2xW5DzwAAlH+gWzYVYqvvzdokY4c1vt+u8/dXUBBZLCd5ISTx1+fK+ndA9/zj q7m9v8YE2yV7fieBefCO1w5Vh71oru4AtTOZjhr4iTaPZh4ELW9PNrUkvYhyKiidn8Mf YY3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734980412; x=1735585212; 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=Dhu35mDIb/3A2ITYiT2TdbY19VVUfLsBSSpE3vJF3ww=; b=eBI6qkhgNTeZ8cqG4+AHbzZcmPj4+AIrWgJwmHSAMkYVlR91B3F5ZHauJucXx37k3v M5ORL2YzxJKe+wkA5crkV++5m923RMf/smAUDht45c00OYFh9J3TPOvtMj/CIVFcyZUF kMVEnL2dFVq3Hc6sT7kvmzRdgKNRnxRrusJMMIZ4gTKgewBv4WUXweio9ADcxTRbKg2g 4q4fkjuezrLD/xRiD1e+q2j4wNwXvycyfB5B8T6hX0RQvYO2croablnECAGSURIf3qZN qiL1iPEmVo4ebCTYUF70M1PrYJaDFC7tQ25xVWfe7Z46Sw4sUIHCyovC9rSuHUv/eOdz aG1A== X-Forwarded-Encrypted: i=1; AJvYcCUVWpZbgXNUQM9z+/pHQqeIGznO/VzfuQZIOtmYU6xjERttcMrm77kkT1guCqKU+6qkw1jm6uURtA==@kvack.org X-Gm-Message-State: AOJu0YysoQmnswNddZBPPfFLOG6L/FMjdkK//5hbHpfnhLjrbLAEnmTq z3EwKGtuT/HuYapoTMWelQpbP4WzzF3eBxkb9GPaCNSkkJvFAt9ubup5j6pKyt31ELTdP5m4t9u PjmgHP2kQddaq5mC7kMFh6tOT6q4= X-Gm-Gg: ASbGncuYrVpOtzh9DnbWnwZHifePKCPFVW9Emm0f7NUT0SHmK7AuFREnMM1kmhwvGmy oVZ1ncRk5G059EmuTJvqNRnCsRHsaa40KHyZWWUs= X-Google-Smtp-Source: AGHT+IEA0LI4ESWdIbKOz/fFFxR5L+FSLunPLXsuHAFLCFmN6T73zZeJjA57iOlvw2bR+9GwzEmnjTZVJXNS/Tmg6Yw= X-Received: by 2002:a05:622a:302:b0:467:6e88:4548 with SMTP id d75a77b69052e-46a4a9a6203mr295471401cf.39.1734980411992; Mon, 23 Dec 2024 11:00:11 -0800 (PST) MIME-Version: 1.0 References: <43e13556-18a4-4250-b4fe-7ab736ceba7d@redhat.com> <968d3543-d8ac-4b5a-af8e-e6921311d5cf@redhat.com> <7b6b8143-d7a4-439f-ae35-a91055f9d62a@redhat.com> <2e13a67a-0bad-4795-9ac8-ee800b704cb6@fastmail.fm> <2bph7jx4hvhxpgp77shq2j7mo4xssobhqndw5v7hdvbn43jo2w@scqly5zby7bm> <71d7ac34-a5e5-4e59-802b-33d8a4256040@redhat.com> <9404aaa2-4fc2-4b8b-8f95-5604c54c162a@redhat.com> <61a4bcb1-8043-42b1-bf68-1792ee854f33@redhat.com> <166a147e-fdd7-4ea6-b545-dd8fb7ef7c2f@fastmail.fm> In-Reply-To: <166a147e-fdd7-4ea6-b545-dd8fb7ef7c2f@fastmail.fm> From: Joanne Koong Date: Mon, 23 Dec 2024 11:00:01 -0800 Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Bernd Schubert Cc: David Hildenbrand , Shakeel Butt , Zi Yan , miklos@szeredi.hu, 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-Rspamd-Queue-Id: EA0C34000C X-Rspamd-Server: rspam12 X-Stat-Signature: 9ei6emkcg7yyy7fh6i8xzewwcz1eztba X-Rspam-User: X-HE-Tag: 1734980383-404726 X-HE-Meta: U2FsdGVkX19XtJWS8YfDC46t+qfncgQg1tn3diN843UO09CnEVBmXnAm6ydUd39BHkauJaxulFZQ2cVBbrCuVZsQGAawDi72B61v5uWyB3OPICdueboAYSHMUpInF11Lpa9hsM26B6n7ueZ5vjMlpaG9w6I0KRGZra9Te2eOTjVg6MPJJZov3qQr1a/7sksGt5y0LoNXyRdS5WA/4Dy6t74se/fjILwryDtN73vCS8R9mXo3O9b1hrF3RFVZLMXM9T1WepAStLsrO2whUZJpv4AZjSRtvdxFMTG/eDlCrdQ3nIK3v8Ls7U9YAhBGYSuEWo5+8z/Iqm53jPMyWXVICKe2dWrpaaHnyd0ZoQ/zgkgXr2ErtaauF3T2KYxnZ9qYx0KMBE/lHKbPf0dPUsPPxdjx5cf42JmApMP22W+HpFdpSdjQUlWIQ0r4lauXgZiztJk0xYQ8fjlf7QapkzcSLyibsUPuUuOk0PzsF1ry750i9lmLMeRwqWGU7C5PRqxS5E1taFunbq18KrP0T9O0XGW2I1L44On8jlq/gXkxGCaD6GGyaD3jhwCvrruuuLodj3zTvK6/UzpCzph7f71w8pQTJHAwdg1QXmMEhSL8j4XLaBc7Zd2B3Z8Ktlk1zQ5P5IYMExRC6Vts0ocbS+mlRT4JEuU5eUHXfrXLe3ol+9eai+UXccxnIBCW8cFEiSQL2qIC/QAjeT7wu0fdlxwmemGAOvTKSIXX5yE700kvmre60LgvbsQDWUQfv76isYtXX0Ce1hpE+4BXDYm4CUOSuDX6BE9+pvqn9oLIDd2RHwnri3Pp7NclCxw0nefMiVA1lKNTB7lFGKWxzY845o39SHfe+kE+bi6Tzuls0fIuZ6anUcbg74wgn4AMAX+TmYegaBAqwg00Z69I+ExOC+FnyOB21J0k+7kPumRhUdviEWXxclL0XLngO0zwVvPwYW6oU09IzGbjARlVYGsVAVh mPHG4/dr J0uXl4Y/mMx7mjlhOpPbDDWz97ewJAApZyXOC6K9UnP3Xv4yhXVD0SWRe5UhmdejNCdFkwJ6oy6qqECVvTKTBI6tpW4P2iib7+UjCS0q+AS7RVnI73RiObGqxmVCN7W7EIiWmTwde7/aGJKGYL7ghG0nHfSZPkE/CkHyrnjNCyDe0+vZxswS0Mu+P4EJIvPIpYJ8Nksu9DDXzxBR8CMHe1/g2RQ9ViJIpSVqMXyytO2T+fAmFx90k6UzjqI1bdxhVKeEI09DJ8rWp2qs01B8ywvhYtbI2IPmvWSv5fw0DS9sH9BXNkeNtc7lIrPGKVc/2k8Qkq/FQ37G29eGrWiLwAooLAML4SVGgiDBTHyNmikLUs/812+ks9EeB1y8X+Oe2aSLRVqDCusY5V+c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.380538, 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 Sat, Dec 21, 2024 at 1:59=E2=80=AFPM Bernd Schubert wrote: > > > > On 12/21/24 17:25, David Hildenbrand wrote: > > On 20.12.24 22:01, Joanne Koong wrote: > >> On Fri, Dec 20, 2024 at 6:49=E2=80=AFAM David Hildenbrand > >> wrote: > >>> > >>>>> I'm wondering if there would be a way to just "cancel" the > >>>>> writeback and > >>>>> mark the folio dirty again. That way it could be migrated, but not > >>>>> reclaimed. At least we could avoid the whole > >>>>> AS_WRITEBACK_INDETERMINATE > >>>>> thing. > >>>>> > >>>> > >>>> That is what I basically meant with short timeouts. Obviously it is = not > >>>> that simple to cancel the request and to retry - it would add in qui= te > >>>> some complexity, if all the issues that arise can be solved at all. > >>> > >>> At least it would keep that out of core-mm. > >>> > >>> AS_WRITEBACK_INDETERMINATE really has weird smell to it ... we should > >>> try to improve such scenarios, not acknowledge and integrate them, th= en > >>> work around using timeouts that must be manually configured, and ca > >>> likely no be default enabled because it could hurt reasonable use > >>> cases :( > >>> > >>> Right now we clear the writeback flag immediately, indicating that da= ta > >>> was written back, when in fact it was not written back at all. I susp= ect > >>> fsync() currently handles that manually already, to wait for any of t= he > >>> allocated pages to actually get written back by user space, so we hav= e > >>> control over when something was *actually* written back. > >>> > >>> > >>> Similar to your proposal, I wonder if there could be a way to request > >>> fuse to "abort" a writeback request (instead of using fixed timeouts = per > >>> request). Meaning, when we stumble over a folio that is under writeba= ck > >>> on some paths, we would tell fuse to "end writeback now", or "end > >>> writeback now if it takes longer than X". Essentially hidden inside > >>> folio_wait_writeback(). > >>> > >>> When aborting a request, as I said, we would essentially "end writeba= ck" > >>> and mark the folio as dirty again. The interesting thing is likely ho= w > >>> to handle user space that wants to process this request right now (st= uck > >>> in fuse_send_writepage() I assume?), correct? > >> > >> This would be fine if the writeback request hasn't been sent yet to > >> userspace but if it has and the pages are spliced > > > > Can you point me at the code where that splicing happens? > > fuse_dev_splice_read() > fuse_dev_do_read() > fuse_copy_args() > fuse_copy_page > > > Btw, for the non splice case, disabling migration should be > only needed while it is copying to the userspace buffer? I don't think so. We don't currently disable migration when copying to/from the userspace buffer for reads. Thanks, Joanne > > > > Thanks, > Bernd