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 7FD5BD2F7C6 for ; Wed, 16 Oct 2024 21:27:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A1C76B0083; Wed, 16 Oct 2024 17:27:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 12B826B0088; Wed, 16 Oct 2024 17:27:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0DE16B0089; Wed, 16 Oct 2024 17:27:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D06B46B0083 for ; Wed, 16 Oct 2024 17:27:49 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 83F0DC03FB for ; Wed, 16 Oct 2024 21:27:38 +0000 (UTC) X-FDA: 82680752364.25.468A5C5 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf23.hostedemail.com (Postfix) with ESMTP id C131A140015 for ; Wed, 16 Oct 2024 21:27:41 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jEN01+cD; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729114020; 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=H/tA/1ocUtWMaIds/iC4Y3qO3oArcv/xVKZQaL3TzUI=; b=ngc25derS1Byr3QrYCYLN8iI90K91LiDsv0R70fBXx9ALfwmhwSyyK6vUdFoP5wYiUDAAM Ox65wh/oCWGj3AA3fUpRSQxIWb+zV7JKw44wQuGTTQZWnk24SjDmxGG0GitaLEnYrWEkMJ OJ2gFAlnvoOWLXom9DFuiAUxSvr51LM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jEN01+cD; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729114020; a=rsa-sha256; cv=none; b=ktrTpiqxDrNCxTMuPgTdYc8VC1z+M734xPI0qf2wyBsa40ISfJHVdJC/4rvenRYiSd4mG2 Tdrddx2sjrQkKz6GnA5ShVFvwPM0TUMeI3H0I8wpvMMmNtBFu5bTk03mBKiUOxMVuh3nSy MVJHj5dflFEXnuX2pcu6HnCLus00JTs= Date: Wed, 16 Oct 2024 14:27:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729114065; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H/tA/1ocUtWMaIds/iC4Y3qO3oArcv/xVKZQaL3TzUI=; b=jEN01+cDRcz+4WkeNRRKfE/C7fC9yvlfooyl7lFOic2lq+v88fC2SiXr8QI0KGpR1oSpHT oKnYchWpERz4v7RWspPS9DpF5ibfk+D7IW0L1TmCO4AW/jiiIpE+FYR6OJOp2rw6cDFO04 HgC69RuhWYAddBcGrSU+D2XsfpNRSG8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Miklos Szeredi Cc: Joanne Koong , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, bernd.schubert@fastmail.fm, jefflexu@linux.alibaba.com, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@meta.com Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree Message-ID: References: <20241014182228.1941246-1-joannelkoong@gmail.com> <20241014182228.1941246-3-joannelkoong@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: ah39jicmg4qs8zcxo48bqyo7kce95gxt X-Rspamd-Queue-Id: C131A140015 X-Rspamd-Server: rspam11 X-HE-Tag: 1729114061-960865 X-HE-Meta: U2FsdGVkX1+QGTgxscKqQIOQ1yfbyL2fHenntewaaA7nZ6ybu62bRRhY7Ws3RkHmdP5YVCumObxyddnbEJ4hyMxDwOXUxZv+Zxh4VYCQhIzbw2ZXB5JcBzMb3H0pZTBHbfDWuezwgnk0TrRXvoFz0FkcuAr9OL/eTwstB61OUcYmg0JyR5MF1Mt1sqnNzNuNCQmRg7gd+GyC+3GskiymWP/w/kDTu5fb7RE6TM7aTKt0XPBYRZnQoXTzCQ32V3mnHFy1KIhiEm5QJIPVLqXl4keGrH8vvNi94jYULIUW7M2OIPbWB3f56MUYEvk4vV/c9haYmztUfWKZYwy4ho0H0IQbm5VLQkolPmS+9yieOd7H1AxyhpXQ1Gz11wkwxOgY6/lbrdXSEJkmodqf2nQFSfbngcZzOJ6eYEO6JkqtpHl1WXOuwJBi0WDT/EIaaP1PyPQXnQfi8aQI2sYBM2ndu/secxRtaa6o7+UPpG8wVsi5Mpq4aPP1qXUy2dESTDuSQ0mikIrmOotli/4kM2nhDtx6u0o9E1tjANCXymlb+5w6LV50jluu7IJ5Iuoj5M8/cLgkU2jkAAzIfmBP1N8q9juICOXxH1U0yzrtZGxkO/WeIzyUl/sIcx0n1fZ1ZMuaUvwZMNHXRL028h+74Pi6Pq0oOJ0fUuicmXT0vXXCtDLqa7ikFmnRrL+cULjf19MGDHrO8JyHK7Amk6aIkIdJ0XpwlgsvF28ySv+rCX0K7X1/jvCfbl+8ekK6wC480cZtNC7vzbCD1VLvrAvtLzqSW7OhBq6T3IFb6+Uikg52CDgu5hVVVnscyp6Vp4oSoeRNfgLog93uNWV4d12qYyI0ODy68QXMNElzc/2qTOVfVK43zgabwVmNWPM33PUi56RYMr4gw80e/9Dnk0jxiwOtJR+/RzVC1Y3xXIOyNTAj7awqKIV+7DkLEKBVAubgH+pNB9+MSLzrjzZSZNIPeB0 JpVJr2BE 3Z5ymVhweLgMK7Y8IE97cd6VYCBvmKUcMk/UOzE94eVf/6efunJ7vutVc43f7l56ZbDE3dueSoGbOIw9T5LYA48mFOeyvMfdsFIjCLftp9AdWzj4af+n+/7ma/JyztmpDuwQQKkuA2C5OhYxyPubXTB/svg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000090, 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, Oct 16, 2024 at 08:37:12PM GMT, Miklos Szeredi wrote: > On Wed, 16 Oct 2024 at 19:52, Shakeel Butt wrote: > > > If I understand you correctly, you are saying fuse server doing wrong > > things like accessing the files it is serving is not something we need > > to care about. > > I don't think detecting such recursion is feasible or even generally possible. > > > More specifically all the operations which directly > > manipulates the folios it is serving (like migration) should be ignored. > > Is this correct? > > Um, not sure I understand. If migration can be triggered on fuse > folios that results in the task that triggered the migration to wait > on the fuse folio, then that's bad. Why is it bad? I can understand fuse server getting blocked on fuse folios is bad but why it is bad for other applications/tasks? I am wondering network filesystems have to handle similar situation then why is it bad just for fuse? > Ignoring fuse folios is the only > solution that I can see, and that's basically what the current temp > page copy does. > > Sprinkling mm code with fuse specific conditionals seems the only > solution if we want to get rid of the temp page thing. Hopefully > there aren't too many of those. It might be a bit more than sprinkling. The reclaim code has to activate the folio to avoid reclaiming the folio in near future. I am not sure what we will need to do for move_pages() syscall.