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 187F5C0218D for ; Thu, 30 Jan 2025 21:48:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 836372802A4; Thu, 30 Jan 2025 16:48:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E63D2802A3; Thu, 30 Jan 2025 16:48:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AEF32802A4; Thu, 30 Jan 2025 16:48:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4AF1E2802A3 for ; Thu, 30 Jan 2025 16:48:50 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B37D51A032A for ; Thu, 30 Jan 2025 21:48:49 +0000 (UTC) X-FDA: 83065458378.01.B039BE0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id 7690220005 for ; Thu, 30 Jan 2025 21:48:47 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="Jp/++nzV"; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738273728; 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=CQEc+/G2RJpf6STGUAzJPzi2XVauipWKftAPOBfoZ+o=; b=ZXnxxxq+S6b4OOHX6zaq0iw/ofYvcuIVbkJWMrxuaeurK9AoF9p8vRlOBlmzcLoJ4LDFz7 WfEfQilnRRePH7tYHwaZ4Xm0SUFmkXrwvXzuXACdRBwUBM6KBFpmiwQL83TxhhmtfFI1MW cBKEhhrRdzdxdCZkcrsomjAPTi7gsTc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="Jp/++nzV"; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738273728; a=rsa-sha256; cv=none; b=LRk5luKm+qRLgt21MeNAYVUwEflMuPHFLxqYV1cjH9jkqwoMs+t83hYc6rNHdRBbpoLtMY GlhMuuu+bQJbRu/GvholnwLczSutX7dNefCcZY1L1jD6DnBbXLzHk9xsDZkOqA8pjQBNVT iHbmf02E0b1PdZr08LV9JU447hzhba8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=CQEc+/G2RJpf6STGUAzJPzi2XVauipWKftAPOBfoZ+o=; b=Jp/++nzVTGKhFinbZ3B7Aybaha trmHE86Fzk1278Qq3G/Pmuz/BtLmWBa8Kd1TEahkz6ijUFvX0USmpYW0uQfmqnIOP47fpJUOoQGXd OTg49d6GNTC8T/ZJhLfxef/mXef9ETTSw3Tb9mppcRIqN1SUBU0YRjAhx21qMsBtcq5bGBpEaXy8h DR1ePg+YZieryn/PQYGas3UUbDSpf2J84Cy7GRcRqTsO1tICBSfmZ1s3sG1jhx/b39oDcEYr+9ZoG 0WjS2mBir/i5IZNlhsqSXYdqjdoPEQrm+TtZbFusgqzDg1gNe1V3kJsmW6zOZWfFGFphNaSsUYkKP iNdwlqZg==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tdcOw-0000000DnVA-3nb0; Thu, 30 Jan 2025 21:48:42 +0000 Date: Thu, 30 Jan 2025 21:48:42 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: "lsf-pc@lists.linux-foundation.org" , linux-fsdevel@vger.kernel.org, "linux-mm@kvack.org" , Jeff Layton , Zi Yan , Shakeel Butt , Joanne Koong , Miklos Szeredi Subject: Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable Message-ID: References: <882b566c-34d6-4e68-9447-6c74a0693f18@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <882b566c-34d6-4e68-9447-6c74a0693f18@redhat.com> X-Rspamd-Queue-Id: 7690220005 X-Stat-Signature: hjw17euy54anpk5ddeh33owtnu4ssjne X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738273727-846700 X-HE-Meta: U2FsdGVkX1+b4OPx+NHJlHqekDEd48pS+VSeZPd+hbdNrnxqXhoPRWyQ1EEPxx/JtI1kNoOLO3eowCWUqfysAMhKns5PVoFT87i0Vz9pNhOC/cJ7tHqe4WA0I+cXLAOudRxYjR/IOM9tEOGD2EIRUqgyo1XvLQSBgGneLkrbZIf7rT7EPQ1bqv3FEYdO/T59Y/6lDGhEGKnCzoatX+Y4A1wvbn4whC8FZqKk/1mHoEgJUtUzM3zBR2aBC3t7FEAvJr1Jsbpc9/kqnjm59ezLOTb5PsqicmfHxsl9UGciTXx8r21uI9KQY1aXoa7J4HntzKYMX6P36+ESrGBvdihVaCvHz0b8We3VuhIuQ4CZ9zIbfCZDQ52lde83VJoY9AYBs6DOENOfAntyMPiCNCbum7oGcxLn9okwP9vm4G1h4ZcF6AjwnYB+pXyAeUF4cZtOcLCRVnczG0EpYE0CoEeWzqXPcm3FZphY4SyffQdygHh/htlgquGUelC7K8l6AE5+ZiLnxFGosWqpx4l4j7EXV1zoX3yz1eJ5m70EnY5AdvV1nvKXWc4HtIizUN4Htg7OvhF26ChyQ62akSZXZnx66mRTvs3NxQ6fcaQVOjdR1LMOtDs6UheWrNGSJyf/VLHaJbdQpOzKdhziSbYhNO2K2EA+F5+8nXVvSvnC1hV9bD3/Egm8jJmTH9VbqMbWyu2vach3TNFdzNbIwOU9vvSgCmetlmXtia9WvuqRkQm3OKXBeZmmHb7/pnzRK3660rsLdzbmM3eOdLaM94TXrCt/6qHaaJ6SxblHlyo8hEq3893biVxGroO+ehNaz0xI//jynWAJN5GKv/51el3D+ptHJ4VBAj0CHEC0HGFe8EFQsO9oYAIA7wiH7ElNYeWcvtrr+Q1bKEyENZjY7tnG3gdXUtYTKKJNXKrkg26yUg9CCQviG63eyTnjkcWFlB9jgN/e20jdXX3A5kVefqq56FV BhQFurXU 8hlOmxCUeFoLK0ihrf9bRJcftHM+srGjDs87fMjr4l/7KkVCkmNpf1i/ftCLYW0qKZVrbCemxSViPw413n83x6l8atgg52Ha0SBHBKKH0Q+eLbYezLwf3Kwg86+OGkMPlEd9+L94IZPpSj7KVTtPysFL8zf0RLoA+UwrPDrhy1aDAmZJLzIWlnpONEOytCqDV+o29TYYqb3qSKlU2IIB/Lq+82/ZlyX/zTy5KpT5M6DFaUAByP2B+3FxxyGZZn7vVykY6Rva9ytQMKes= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Wed, Jan 29, 2025 at 05:10:03PM +0100, David Hildenbrand wrote: > As one example, in context of FUSE we recently discovered that folios that > are under writeback cannot be migrated, and user space in control of when > writeback will end. Something similar can happen ->readahead() where user > space is in charge of supplying page content. Networking filesystems in > general seem to be prone to this as well. You're not wrong. The question is whether we're willing to put the asterisk on "In the presence of a misbehaving server (network or fuse), our usual guarantees do not apply". I'm not sure it's a soluble problem, though. Normally writeback (or, as you observed, readahead) completes just fine and we don't need to use non-movable pages for them. But if someone trips over the network cable, anything in flight becomes unmovable until someone plugs it back in. We've given the DMA address of the memory to a network adapter, and that's generally a non-revokable step (maybe the iommu could save us, but at what cost?) > As another example, failing to split large folios can prevent migration if > memory is fragmented. XFS (IOMAP in general) refuses to split folios that > are dirty [3]. Splitting of folios and page migration have a lot in common. Welll ... yes and no. iomap refuses to split a dirty folio because it has a per-folio data structure which tells us which blocks in the folio are dirty. If we split the folio, we have to allocate an extra data structure for each new folio that we create. It's not impossible, but it's a big ask for slab. It'll be a lot better once Zi Yan's patch is in to only split folios as needed rather than all the way. That problem doesn't arise for migration. filemap_release_folio() is only called by fallback_migrate_folio(), which is only called if the filesystem doesn't provide a ->migrate_folio callback. All iomap users should use filemap_migrate_folio() which just has to move the data structure from the old folio to the new.