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 5B7B0D1039C for ; Fri, 25 Oct 2024 01:38:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E1D776B0099; Thu, 24 Oct 2024 21:38:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DCCE86B009C; Thu, 24 Oct 2024 21:38:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBB7D6B009D; Thu, 24 Oct 2024 21:38:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id ADE3C6B0099 for ; Thu, 24 Oct 2024 21:38:38 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 583B0140304 for ; Fri, 25 Oct 2024 01:38:18 +0000 (UTC) X-FDA: 82710414528.21.6824FE4 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf29.hostedemail.com (Postfix) with ESMTP id D66D612001B for ; Fri, 25 Oct 2024 01:38:06 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=hGD7323b; spf=pass (imf29.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.119 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=1729820162; 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=3fjz4BfrC3wykJsJfwFrwxl/YAJeU7MAIcR+vHCE4mA=; b=22VSG96C6hn+o5E38A5L1Y8tih9ywVBSIPzQw3LGTmrzM60MFAXDtex2YBM84ZHLhOdCfC G0KrJRpIPZDM4YFpiGdUXjjEMGmQiJ+DUtEfDSkkGfVI5nCiCFaIeV+ti2t0goi15rXIXz rjUZyWlNwy9FRFzTy9ZhngJDSYpfeQ4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729820162; a=rsa-sha256; cv=none; b=lu7tk/I12UAUTZkBVGACeHlxDlAOA7cNL4xnMsGlS5YvvCD34dZ8fKpHFhw+7I4niTdOU0 kyoc7KTGFfu+tsfh6S56TMSazik37pjvWEs/qXVZ2T44klCtVnxCCGfKO3Awp430KmUmQr WBYXNwDn6uRoPBLKWMl6BQatwtwMWd8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=hGD7323b; spf=pass (imf29.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.119 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=1729820307; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=3fjz4BfrC3wykJsJfwFrwxl/YAJeU7MAIcR+vHCE4mA=; b=hGD7323b5kReb8rK1NXosOH0IM925IAeN4tE/sAXJKRuTam3VMEKWgp8qKDydXB6txrBgv46owHENVuTMf6Q+uE7aFhlWQbrdteuiw24Mz/H5Z3z9uPDYtLuVv/4boBCoHKg+SvRqQKMmAg5XxY6SnD6nJwthvGRqt4WoZWOSys= Received: from 30.221.145.1(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0WHqdu5c_1729820305 cluster:ay36) by smtp.aliyun-inc.com; Fri, 25 Oct 2024 09:38:26 +0800 Message-ID: <3e4ff496-f2ed-42ef-9f1a-405f32aa1c8c@linux.alibaba.com> Date: Fri, 25 Oct 2024 09:38:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Joanne Koong , Miklos Szeredi Cc: Shakeel Butt , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, bernd.schubert@fastmail.fm, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@meta.com References: <20241014182228.1941246-1-joannelkoong@gmail.com> <20241014182228.1941246-3-joannelkoong@gmail.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D66D612001B X-Stat-Signature: etbopecugu4dojuqdpdm783zn4q6j8tw X-HE-Tag: 1729820286-61797 X-HE-Meta: U2FsdGVkX1+LLNcMw6ysWV+l68uJmOM09/EGHYLSOh8FDHgWmXoJSHSakHK/rn/UsY5tbb/9/oFfC8HkLE849/eTHrtk+up27WBfPYDu0Y3S4N0/QncLueFy8u8AbU7tU1gV9tlxbaa/xPhiYB+xRiB5PgwJHGl5+x0VEgwllYluZ6+zX1S1QYpsfeyUG4qks8K3SABtWTMC4/ISnhlej5sQwBRbB1gylNt4v0xBpadorijZRz35CTkOEjzrIT+07ZvTKKoxqXIHvivNJRZbYKbO1LWViRk/GAEqsFFz70GgvoJTTl9XFSLmWIVwAt6GrCq1P4AmPvkS6ipqGEONlbWnV0NHcp1OHzT4gQ0a+X3QPWYoWXbEY7vOe6rqmjdJehOuN1Od5UJmilxjthykickGPtXR+x+Sugku0ZbU5ccsr3OYwdVoKkhR2KLs+WbRAdq6J10Lb7XloHEDRndN9aWeLqkckE7PEo/knoZEja0G9muVoH45F0Hmhptp56/yFjP7UqmtYHIUQl22r2xQxSX9o1TZTHkB93Sg+zeJf1VxfDOuvUkX4wujvNnKeR8Nn7uDnS9l82J8njyCA9O7bmG6XczLStn6/qeOW9pvQMZh3TBR6aYdUDfSDZDkWOv22dRkGb8MVWu9/Nw2/EMGNuwrz5d8BFyGIDZr+Hdjyt9V5dnc/DQM7cd1it4zqZzkMVXPQ54nl8iB8HrXJooWxFps735z6Z2oZ5TqxS4XhrdGeln8p98pFdUC6MkyQQDq7JWzHNLy+gEPPRQ4dETwap/hOzPjcRw6kdgVDDbvabtriUAQoqCPEWb/pMg/ripXQT0j2KXxi21irGts31iSucOgRyRxuBYyqfkhC5Hz5Hvnbvhs/BliL58AU+Jaua+SLI4LZ3i7B04i//kD9ornrwsc/YpxpqIXBWnAbkJp8WOT+y6jUJ98XYVz+rP6Ry203LTiAI/ovif5y1sYpDT ncEd6JnF 8A8zKOlZ5u6i7xV7oGtAEQGeUhqmscnYl0DwxiM8WMH8Vo7vPrhoLs0qpBqHIfSR+VKf0rxeIVCEmpKwLJfCCfmXcjsaykU2rAXv28FXnBhRSqD5lgOWEaLgU0WgZ0zq7TZwM2WiWDjE0utNP8S4SuADlKpBURZ8R77Ah4O1JQ/02H1VTUwJ+MF2yE6ynysm2Q8N6hxSP9VcqL1K96moKyqPLB011h3d1omN7a3xV14xGvSfW2aIcP9OaB2HzzBx/a3SvRnetXBI3vs67joCc0Wu5Hc+8jRreTrEWm5ZYZab4FH7dRvqI7uwq+b4enqjIne1oeFK81SmjrV6uua/SLICdLF3Np158cHPxQRyo47WJqNA5d7UOOmHTxyDrhDpFSo8dEewt1yxbt2wmhC1Xuomc3A== 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 10/25/24 12:54 AM, Joanne Koong wrote: > On Mon, Oct 21, 2024 at 2:05 PM Joanne Koong wrote: >> >> On Mon, Oct 21, 2024 at 3:15 AM Miklos Szeredi wrote: >>> >>> On Fri, 18 Oct 2024 at 07:31, Shakeel Butt wrote: >>> >>>> I feel like this is too much restrictive and I am still not sure why >>>> blocking on fuse folios served by non-privileges fuse server is worse >>>> than blocking on folios served from the network. >>> >>> Might be. But historically fuse had this behavior and I'd be very >>> reluctant to change that unconditionally. >>> >>> With a systemwide maximal timeout for fuse requests it might make >>> sense to allow sync(2), etc. to wait for fuse writeback. >>> >>> Without a timeout allowing fuse servers to block sync(2) indefinitely >>> seems rather risky. >> >> Could we skip waiting on writeback in sync(2) if it's a fuse folio? >> That seems in line with the sync(2) documentation Jingbo referenced >> earlier where it states "The writing, although scheduled, is not >> necessarily complete upon return from sync()." >> https://pubs.opengroup.org/onlinepubs/9699919799/functions/sync.html >> > > So I think the answer to this is "no" for Linux. What the Linux man > page for sync(2) says: > > "According to the standard specification (e.g., POSIX.1-2001), sync() > schedules the writes, but may return before the actual writing is > done. However Linux waits for I/O completions, and thus sync() or > syncfs() provide the same guarantees as fsync() called on every file > in the system or filesystem respectively." [1] Actually as for FUSE, IIUC the writeback is not guaranteed to be completed when sync(2) returns since the temp page mechanism. When sync(2) returns, PG_writeback is indeed cleared for all original pages (in the address_space), while the real writeback work (initiated from temp page) may be still in progress. I think this is also what Miklos means in: https://lore.kernel.org/all/CAJfpegsJKD4YT5R5qfXXE=hyqKvhpTRbD4m1wsYNbGB6k4rC2A@mail.gmail.com/ Though we need special handling for AS_NO_WRITEBACK_RECLAIM marked pages in sync(2) codepath similar to what we have done for the direct reclaim in patch 1. > > Regardless of the compaction / page migration issue then, this > blocking sync(2) is a dealbreaker. I really should have figureg out the compaction / page migration mechanism and the potential impact to FUSE when we dropping the temp page. Just too busy to take some time on this though..... -- Thanks, Jingbo