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 DAF07D3C549 for ; Fri, 18 Oct 2024 05:31:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EDF76B0088; Fri, 18 Oct 2024 01:31:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69EBC6B008A; Fri, 18 Oct 2024 01:31:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 565676B008C; Fri, 18 Oct 2024 01:31:43 -0400 (EDT) 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 384F16B0088 for ; Fri, 18 Oct 2024 01:31:43 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 517FAC0190 for ; Fri, 18 Oct 2024 05:31:30 +0000 (UTC) X-FDA: 82685600592.15.62B988D Received: from out-184.mta1.migadu.com (out-184.mta1.migadu.com [95.215.58.184]) by imf14.hostedemail.com (Postfix) with ESMTP id B3B6210000B for ; Fri, 18 Oct 2024 05:31:28 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NpHEZ29Y; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.184 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=1729229356; 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=MMiNLJFyavBpZ4JXtIhgjcdmUGIO3nY80lFVYxM6sEw=; b=HezT9Ien6n7ANQb1+vHWQHPAQgbKF2Ylae7Jv1rMLjKTI94Q0lLPPSjANEQYz8CQD6KPs6 BaMIgzlOeQ3X1owGJ6RFO/w1hKQipK8qoNECc8EaXPMjwDniSZ9QS8bUu1Y2DcHi6VQeb0 LG7ztdX6FSQzQH3uqAvW7d6xw1xx3ZU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729229356; a=rsa-sha256; cv=none; b=tWKYgG0jkedyDb4tBaHKzjmj4Robc53nOmYrgRnG4VZ+m6gAnGms4A2ct4JGm7uJ8WU5tg 9aws5uAzjOf1oUCsI69N/VKGlHZv0CQ0agCHzT9CDCY/wP0CBKLBO2Oaz3dGweGquVgBmn AuqSew40wuGuRS6sPcf31t1HtQkZLEM= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=NpHEZ29Y; spf=pass (imf14.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.184 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 17 Oct 2024 22:31:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729229498; 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=MMiNLJFyavBpZ4JXtIhgjcdmUGIO3nY80lFVYxM6sEw=; b=NpHEZ29YjHQkZeemGGygG84jYRx3xOAUtSoL4BTyHVv1VaGst+b8x9yyEDkoZLP7z/D9uN y3rtgvALXhwJv4HhDtEjulM5fERq2qAY8ZcgrW5iSmmLvvCqIA6h75wS/ipQ5IMGukafFk NrtFc2G7UP6B+uODa5BJc5BQ7Tf8sN0= 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-Rspamd-Queue-Id: B3B6210000B X-Stat-Signature: ah3ujrrxu4hohwa6g6bhxmi7873cxj9w X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729229488-716310 X-HE-Meta: U2FsdGVkX184k8vGESlNY8Wny6T4C41jGHDOGynkxJMNu6f40E2dOZF8n0gzEJfALsFtrcDg8Hz0VWJH4RZXJj8Z0V1Y9Faa2+m813mFe7L0EQzBhnlbJFTMkddABbHsgazjo97IiYmtzy5wTS0uYFSj1UwPwiK2Ow6gG6NitsdBpy69p4/y7qmAwTIsWWT7togK/rebivd73MewJ8hBC0NwLOnc90+MMW3Qr3D7m6gn4eQXvG5f4Y2vmyGmdZF5a9MbbxhlpoUBAlkdFV3CAZFZnncG9/yaa1pkfClNddTIcQv1ACqycW9Q/3upopHF3Fy0V92BT5CwID/GXAYZW/ink28aLC7h6s0n9N8tH2TMRqap6RmGLgj5ILWRVmylzPCMCA653SKZ44VuzkfQCgdyXsGt9rHGQBiiWSrWvHQi/106X03aAvoG8lMKhQ7fWvHeKgNzmAb1dX4EpHcQ56fqV39JyE9logLhcfifCqo7f0EaFzrDlyNd2Mww2vo+zqbZfhJPWrbsMUrnLwRvEU2+v2JYaf/WMXZw3R47i7bxD0x/Y9/PlnbKxfh7AmeqDn5H7vorMrgthjZKYwKrR6vGmEEqz+Qv+fsItqPa/w1yFVFDtqynU02vke/qFj4vADWjkFoaNWPdSsmr+R1Rj14wf182V0/U05PXDpgiia8AABc8cLwglwd9xqohA+PQtfUaFfvv7XOO+gJm7avUNc0/m5n6i9kagjmTFW52IQ4Sen+AHSqu2wcYfkdACvWxnMaD2zYqwbRZbMDIMOjsuwu3FXeBrro0CaUstiOj3bcuCKVgQ9jYbPvGWtq5ygZAdjeKKqjLQl6kg1kTy/In/yxCQZRZ/YXwLgtawO8xyM4kd8/r8he+HWCXiBXkEcbeiSKSxWf8co9wq48S2DsSRVkAIhx8ZC+loz8mKarcb4UGygJDNvDbsxJ+IIqEFJKnh3dUAAvK4Oe0eNp2HGG 6xUYblnX kGrrcTriB1TTdh0X6tRvEjdILmdftYXn7BKGkmVYG8TAx5X7j4fk/nw7BFnK1X6zU/A4pEC25h6MGU70nnuPH4Yl+YjSpkDIQdDIeXAE733Nlq4TRTOITjfmd4NtapSJS2txL+TJ3KstmL2lsSJehKflFMA== 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 Thu, Oct 17, 2024 at 03:31:48PM GMT, Miklos Szeredi wrote: > On Wed, 16 Oct 2024 at 23:27, Shakeel Butt wrote: > > > 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? > > You need privileges (physical access) to unplug the network cable. > You don't need privileges (in most setups) to run a fuse server. 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. > > > 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. > > Maybe move_pages() is okay, because it is explicitly targeting a fuse > mmap. Is this the only way to trigger MIGRATE_SYNC? It can happen through migrate_pages(), mbind(), compaction which can caused by hugepage allcations.