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 900E2E7718B for ; Sun, 22 Dec 2024 02:47:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED8D76B007B; Sat, 21 Dec 2024 21:47:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E88736B0082; Sat, 21 Dec 2024 21:47:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D50516B0083; Sat, 21 Dec 2024 21:47:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B16BC6B007B for ; Sat, 21 Dec 2024 21:47:47 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 597A81A1426 for ; Sun, 22 Dec 2024 02:47:47 +0000 (UTC) X-FDA: 82921059438.29.5797866 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by imf19.hostedemail.com (Postfix) with ESMTP id 6C77D1A0007 for ; Sun, 22 Dec 2024 02:47:06 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=h0+tlxm9; spf=pass (imf19.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.130 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734835624; 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=ztIIgXsGVtJzNjNG1ZvxiaISD/7oz9lzi8TKDCq5joA=; b=4W1qIA9W2M7nwwHC1fI8tbzRsS1evgJzTuHlMUKMRs6sWfvdRr3EEwdPEnee9mRUBVgxF/ YIXMH4eqe4d9/cm0c7MoFAjjftVlrQ13M/RMf/SEUUhXbqilsXsyx3RkZUmcjAxplu6Mxe kyz4qXrD9Da4NGjZlQ2fbFokG8PIkVY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734835624; a=rsa-sha256; cv=none; b=4wr+/b/17z61VMx47O5rzjoO0rNkt789t76BR6nXJlKJI3PqUXPexD10ih9XOItVOut91P n8ZOCk71HfxTo/fLg3Hn8UYwXAaoplXELI7OS8aO4bsQ/W/GaB302G/cKhylJxXjTakLBR rmHlXfyKfoGK9sjCR1pmJrnBOv16X/A= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=h0+tlxm9; spf=pass (imf19.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.130 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1734835661; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=ztIIgXsGVtJzNjNG1ZvxiaISD/7oz9lzi8TKDCq5joA=; b=h0+tlxm9z2mrVEXBUm6DU8emvbOF0I/1v/H6CWS7xOJcPp/fKDwtZyG/9TGx2i6hr76+OlmeshQSL+1h7G2ukZxYDNOwy1S5A4l7t/fOVSO5A6faJsNK1YxYKnQnm4FA0xnMGSTJOWy95iljcRSVpZaTcYyunq3+GC051vlALbg= Received: from 192.168.31.58(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0WLxdV9i_1734835658 cluster:ay36) by smtp.aliyun-inc.com; Sun, 22 Dec 2024 10:47:39 +0800 Message-ID: Date: Sun, 22 Dec 2024 10:47:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: David Hildenbrand , Shakeel Butt Cc: Bernd Schubert , Joanne Koong , Zi Yan , miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, linux-mm@kvack.org, kernel-team@meta.com, Matthew Wilcox , Oscar Salvador , Michal Hocko References: <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> <67fec986-6a5d-4b1e-a86f-7ecccb1bccf5@redhat.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: <67fec986-6a5d-4b1e-a86f-7ecccb1bccf5@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6C77D1A0007 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: bngfb1tqteqoqn1xi7t8o931ws6xr8jc X-HE-Tag: 1734835626-846701 X-HE-Meta: U2FsdGVkX1/2DRcZUMvXDRnkgTDFjCKDo2ZOKFXDNuz4LhVfdX4f+o/Zvew0UZ3OnO8CXpYviXm4fAfOBjaHEgvV00MEzjzcXhWokG0lOOEuoes57RpjpwhC1tldPAX9dtKxCW37+NwUfc0K5zG8lBsoJ5b5ngZ/+Wgl+EsCFThruey5ryUrVYH6VLzUc5sq6UxfwUsNEBMBZdZZP/3aBi+vVB3J4i+3lT9dMALYE/zj+566DSTW4V2SvGgI7/ki4/OHEYRjWlYcHgdzzEcAnTq1miGS6uhFV74ncofbzwzK3jhZMS+bBCKtzYNtgGxsl/uOEkbXQfID6tfV9ydjVIm1pJwTt6SpEauAUA49cBSS4VoC8jgtiNtlUBj4DakcUccwjiTk5BBwaMyHuR8lfG5CoqjB04YbpvHC3DnvxCTNSQFJk1CHipQrEZmzZuvJdw5Ddu+7MEGbkT4Nl0sU3uRNizW7mS2YLDWCda4iM2wMuzsLGm/CIc5NWOj2HzNGhQgqSHGkaQmUr80ASKn0OxEXK3c283SHb1EoWfbxuQhBTz/YBNj+sEo5M9oaqaHEJjQ1rkZNa8N93lB5e2U325ts5k7ms+rrGwgXmTUmn0kE2ZHcdcAHOCpDv4Phw6Mrf0u1viAGt1vjYsUWd93j4ImM4TtyYLNagbtqyeetTOH088+SkWO2cZNyJTvnJb1qmV6IfrpTq3K1quYWA1oB6mxOsE0XsXWLv9W8b9j1hJtLFISETZXTQurwL1ARBueWetEhu+Ayx1AqXKv5deCZPFSwQOuM7Cglkw4LqNYKcj7NVB/1fwbCDT36FTQ3mae8HozVwWjKO6pZzD8AqJVT6EwohulN1UmzCaEQJuFNQ7xBOp9UN9L2fKHbf1Tk4LPd6gBpT0zuQ6riWJ4Ddbw9JaS6RVDg17VnCr/5ESfhrsfBrumXi0C8jtm7qWlnmmqvfgmGN3e69ouZMx5UCUl i5ogEkHu W2Az0DLXgCTZi0M3QfQZX3bSNsF7TG4R/VtOAOUjvfX+4e9lLRKUOWeQQWnRyh9HJzvEbxkLrnMbpCx+pkby45SOXunxvohbDsw4UeIe3Ifvi3SDjK/cicTt+CAJGCLJI9QI+NfBszaxKLVRghNUDdfmWqsXgXE/8X4vFowNlX9bZ8Qh4ALn9AASecDFP4289mxXSlOzYakzUqiIZ/YjYg0Ko3zjCk9k8CyE4MozKuEfEqef0JbCUn9VvPBmhUWbnhyWurJFB5ZVSPSGaIdncj+Kn6BPCvqiP5pBkptjOhWSai6A= 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 12/22/24 12:23 AM, David Hildenbrand wrote: > On 21.12.24 03:28, Jingbo Xu wrote: >> >> >> On 12/21/24 2:01 AM, Shakeel Butt wrote: >>> On Fri, Dec 20, 2024 at 03:49:39PM +0100, 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 quite >>>>> 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, then >>>> work around >>>> using timeouts that must be manually configured, and ca likely no be >>>> default >>>> enabled because it could hurt reasonable use cases :( >>> >>> Just to be clear AS_WRITEBACK_INDETERMINATE is being used in two core-mm >>> parts. First is reclaim and second is compaction/migration. For reclaim, >>> it is a must have as explained by Jingbo in [1] i.e. due to potential >>> self deadlock by fuse server. If I understand you correctly, the main >>> concern you have is its usage in the second case. >>> >>> The reason for adding AS_WRITEBACK_INDETERMINATE in the second case was >>> to avoid untrusted fuse server causing pain to unrelated jobs on the >>> machine (fuse folks please correct me if I am wrong here). >> >> Right, IIUC direct MIGRATE_SYNC migration won't be triggered on the >> memory allocation path, i.e. the fuse server itself won't stumble into >> MIGRATE_SYNC migration. >> > > Maybe memory compaction (on higher-order allocations only) could trigger > it? > > gfp_compaction_allowed() checks __GFP_IO. GFP_KERNEL includes that. > But that (memory compaction on memory allocation, which can be triggered in the fuse server process context) only triggers MIGRATE_SYNC_LIGHT, which won't wait for writeback. AFAICS, MIGRATE_SYNC can be triggered during cma allocation, memory offline, or node compaction manually through sysctl. -- Thanks, Jingbo