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 2B6EFC0218D for ; Tue, 28 Jan 2025 10:16:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6850280224; Tue, 28 Jan 2025 05:16:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1901280222; Tue, 28 Jan 2025 05:16:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B896280224; Tue, 28 Jan 2025 05:16:53 -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 7BA68280222 for ; Tue, 28 Jan 2025 05:16:53 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 26256AF11C for ; Tue, 28 Jan 2025 10:16:53 +0000 (UTC) X-FDA: 83056457106.22.92EAD00 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf12.hostedemail.com (Postfix) with ESMTP id F03D540009 for ; Tue, 28 Jan 2025 10:16:50 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b="Z1bVri/6"; spf=pass (imf12.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.176 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=1738059411; 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=BPEyMd98vNN+GRTzAXiHc1FCEhyXV1COXKz9r10gCRU=; b=F0Usfus67w1SOfzQ5but+fPF3wZ9jGMrCSk6cgZPYqi5lxIQX8emvMZmaq3xRqkTfiCMMN XlS4p6726IBS5Na666336x2cbG4lzyYOc8R4O4tkY/Al8R5coS58uR4Zh8A0ceSgZpGurz iudaQitZDjKG52UuixwkG9Kx+QOxfJg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738059411; a=rsa-sha256; cv=none; b=tyVWGUXQPfcBmkTGrH1kGQ27dKLekl5ZLBEY3SVw5MCPfMDmTls9sATYyocQUs734ZUkQJ gzpx6C2Cc4ca81BbO5iOeDUJGtc4VMxu0wBbyNsJ+rRBJC72L1KIBiPCubdVH42pfE8M4t fjp2vyCPzCZ+V+FhJL3AXvmJOYAeijk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=szeredi.hu header.s=google header.b="Z1bVri/6"; spf=pass (imf12.hostedemail.com: domain of miklos@szeredi.hu designates 209.85.160.176 as permitted sender) smtp.mailfrom=miklos@szeredi.hu; dmarc=pass (policy=quarantine) header.from=szeredi.hu Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-46e28597955so44993431cf.0 for ; Tue, 28 Jan 2025 02:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1738059410; x=1738664210; 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=BPEyMd98vNN+GRTzAXiHc1FCEhyXV1COXKz9r10gCRU=; b=Z1bVri/6Ynxxb3PtMdxRvaeKbJ112xh1tcSKHouA7Bqnx22iXk9/m0Xzk7DNb6jKgE eZc7JNgzU6SXbbDJOpreQuWJtp2sg8QqSzCIJ4RarGY/XYZPadNNkgoZ0zADcMt8bDKy 5L5xVC6VolGmey+E1rBrWChS2nTD28urzApFo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738059410; x=1738664210; 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=BPEyMd98vNN+GRTzAXiHc1FCEhyXV1COXKz9r10gCRU=; b=rvJoPG6yQiJASd/Ps0L82A2db3Pn3I/mGjaT4Qw/98MycFNmFdnNECRgn1Ib0R1x0k apGTU4xDrqJ/+jj7UD41opEQJqn/bnrsNj+x8lh8j5zvLclxxiDFg7Tw/ZI1U3s6xWY2 oVnLVNlw37GO/fG8mSTij3kv41dNhHziVVry99VsPyUqMLZhoDknTeoEU1bZak7n5XyY TM+OOXSm9jTTwaeZ6m5HJn5gPYmcSp7XXMhNONmaFh86U6vmGLuqf+epluYGtUfLhT1S UDhqW+watyDIsIMldPTJA3y8XsmNgufrFsjUKi08EuRbs8fxvO/dYqMB4W7/ZQ38iu7/ 8ppg== X-Forwarded-Encrypted: i=1; AJvYcCXF6CVHGTjAnArgV82wjlOnKagk5TNAu/9PgPV+vA4Aol30F0vrtElVAwrttmuw7HEafdS2mxElCg==@kvack.org X-Gm-Message-State: AOJu0YzdFqsyNoxa5I0PDwcmrWYvDS8oQyHFlBXWxcgoGh/+lywZ1vQu kpki2pB8WSBJvOklRlLucchRpPAMS3l3oPOWGLITyiKFd5Bd57L9pZFhglxUsGgd3yi6KAslaSW SzCibX7jrdxCc8fLCHAP0UOqTuN/PB0CUkLYwZw== X-Gm-Gg: ASbGnctpQP/jOIq6pk+TgQap4/kvdHxrflb1k+52vrrza32og7+yerwUCSXsnFKaGvk Ck+th7vkkvJrozdLrONJiKwjW3yMPq36OkV2AA5Z7tvMMBXEtinpNbA6N2OXPziDaoSDTVGs= X-Google-Smtp-Source: AGHT+IEMiNHpXGXEKPmWrOqZT6qEgAQmHRQtdJwbZec6UMKf0O/ADxrUOeWzIO8I5hbB90zgwKZh8YB9ZwqdbLxH2Uk= X-Received: by 2002:ac8:5a45:0:b0:467:5f95:679 with SMTP id d75a77b69052e-46e12b986e9mr562673851cf.42.1738059409912; Tue, 28 Jan 2025 02:16:49 -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> <3c09175916c2a56b55d9cf61e4d8c0ea66156da2.camel@kernel.org> <752b098c-345e-4374-bf01-37193b402890@redhat.com> In-Reply-To: <752b098c-345e-4374-bf01-37193b402890@redhat.com> From: Miklos Szeredi Date: Tue, 28 Jan 2025 11:16:38 +0100 X-Gm-Features: AWEUYZmmF-5k5dD6SW6YMKFQrd4EmkWMa8Gy2a9g1PbqqS-FWhT17Hy-5YbTwEk Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: David Hildenbrand Cc: Jeff Layton , 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-Stat-Signature: f4qti8jktx9t65n8nsaqynyypoaib8ah X-Rspam-User: X-Rspamd-Queue-Id: F03D540009 X-Rspamd-Server: rspam03 X-HE-Tag: 1738059410-210358 X-HE-Meta: U2FsdGVkX18OaBJpK3XQd9/2YWsqwUuMF48yti8iclhGCOKavHERuBeSUc4WYrzHQFydCqVTO5RnKarwsGH4xPmMdE3E0srEFCXWhZd7yw2IEI6bkqQkNvVciHbaNBkQxOH6HToCm53jyFjYmUUYW98Jy0ZAGgxlWbOGiBGxbBT97BX1WbymC3lBEcuJ4EcGEC/yDO/plVCtR8FLPdrx82eFnqlI4By/2eOF37zV7C/w3bZEKYbPkI7ha1NcKTRsdgA5TZkWWpw8cUznOHjFpIoM+8lnJt0y90GUf9o5149bBsgY5LmVRdr8BXp2ImElUhfH2Gqcp8T/117FiFvH9q5XNPPjVZQ3oh5AcBVjGN613H4jKgMTvYAGgplmgELZFjiBmeU8HZpLfdKUroPebhZEDARmDLoGakXP5rFr+IZQ5G8RYMUS2SufTYnQ7hx9hc4NO67rTq/91a9ImeCHfJOpRAg+5zD1gLX0QwLSeEHRimcLf70tkenUnhDHxmZeUWCRJrQ4Bp/8smu0HznR6kHMywkAZxCpmsIVyi3Hlw2Ru6iVWI8ZqDLhejL48VwL6c7qDLpphcs6TcmlXUbQHs6Qd8pNRb2wBUErN5bdb5KVw1oHKfbrcZxGJDnjwd3a/IXiopQNf756ATjNwsc8W8a4gJV8asLROTpTn0IHX4mAkfwcvexaDia7Ehk7MOc0hI88qcY128WlgtnfjlHE2TyQGvujns3N+qDJrpoLdwpo92ngpauKiTGJ+Nd8lR/jcNQUHK2CqFoPAP54lw549EyKXK0JnslXzmBM3eB28yR9Qd2e2F0nH1sgbDp2PeT984xJttlPfa94S99bJ1IYv/8w5xjcMt5K/xVmp3ASeWeLyMQS9Gr5d7+745c2/j3FiISMWr6QYbU+x5Q0+mUnjDTi8sXQ5p8VmKBULVtO+fN8DT+sR4OZdDw9+chJ7CJK1A3pSOhmdmEheUhEtLP Qtj3mWKT JQaVMeEXvVuiufyUoyb7xqoBKZ/MqqFpNtEh5QNq06WXcoRXDgVpyo3lBsDwACHrKcwclAiHpBikm8aNmHpa/8KrAOnN00RXKVnP/qq670jKFb8JliKMVXkB6KwpIbI1yNFMemE1HiZtaOoPIrSvJlA/PVaxk1Kf6k473Id0vtQ5wNGM586t2wIWP/lOMk7dnH/JrqC2LvG6eGeHTKBGlP5h/MP0bS9xcbqe3OeCbYeXRAemcrUAjf/F5mRRdcCP04JaKqXCKFuRaQbs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Fri, 24 Jan 2025 at 13:29, David Hildenbrand wrote: > Yeah, that was one of my initial questions as well: could one > "transparently" (to user space) handle canceling writeback and simply > re-dirty the page. 1) WRITE request is not yet dequeued by userspace: the writeback can be cancelled 2/a) WRITE request is dequeued (copied) to userspace: the page can be reused, but the writeback isn't yet complete. Calling folio_end_writeback() is lying in the same sense that it's lying with temp pages. 2/b) WRITE request is dequeued (spliced) to userspace: the page is referenced indefinitely (could even be after the writeback completes). Temp page could be allocated at splice time, which means performance will be no better than with current temp page writeback, but at least it will be less complex. 3) WRITE request is currently being copied to userspace: this should normally be short, but userspace can be nasty and have the buffer be an mmap of another fuse file, and make the copy hang in the middle by triggering a page fault. The request cannot be cancelled at this point. In such a case the "echo 1 > /sys/fs/fuse/connections/##/abort" mechanism or the upcoming server timeout can be used to shutdown the filesystem. So this is definitely more complicated than I'd like. Thanks, Miklos