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 31D80E67488 for ; Thu, 31 Oct 2024 21:53:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85B7E6B0089; Thu, 31 Oct 2024 17:53:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80CED6B008A; Thu, 31 Oct 2024 17:53:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D3FD6B008C; Thu, 31 Oct 2024 17:53:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4CB4A6B0089 for ; Thu, 31 Oct 2024 17:53:11 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 15676AD734 for ; Thu, 31 Oct 2024 21:53:11 +0000 (UTC) X-FDA: 82735247196.13.880CDA5 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf18.hostedemail.com (Postfix) with ESMTP id 387B21C0002 for ; Thu, 31 Oct 2024 21:52:57 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OgVeSaV6; spf=pass (imf18.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730411457; 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=F27qB7pqs4B+H6rgwMgg110YnYCYCyECaYMkJQesej4=; b=yRrPq58rfKFV/dpRe1nZAFnWFVyLS96xtMrSF+Xq5eagwskfkGHiez2ou5IS3ip2zQATTj u34rRb0XIa5CIDTUWIOruS/5fQQTAWiK6/synp08hKomXgFH0JCkjcZeUnv52Jc5cIIOUc f72LTmygf+eCrZ44MKTzbTDrKuS5DAo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730411457; a=rsa-sha256; cv=none; b=qKMMtQBaGCKQgDfZoNV7/xA9QFkOyF3x3pZ7h2suAIFIhv6jZS13iK7jnmKqL2nAjs9qE1 BqObMEZ/GAdA3A3KtKrHCgyw9fHqTbOWOCvZqjlxMj10k5SAYmtP0T0tojnmVsCY0S7qoR 3gOIeOB+jnqQIrLuTszEn1qM7lz7OfM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OgVeSaV6; spf=pass (imf18.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e29687f4cc6so1186979276.2 for ; Thu, 31 Oct 2024 14:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730411588; x=1731016388; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F27qB7pqs4B+H6rgwMgg110YnYCYCyECaYMkJQesej4=; b=OgVeSaV6WSjYU0rWAwua1TovVVdaaE5TDJldh3ULvunayJdk/Ao3wvlATuLZgxB/zF 4W1gbGRGFjcttrnjRbRfNNrYMAQTM4sgZEcuU8uG3D85NVls/04DB3DrP68ENyfRVj67 /8UrvRAzfrrhq5u3tvRoLn0qwWYDR2vYTkTVlZaYR6GFPeHWe5hvYFnWND2hgmr4Akwi lu0mP06DC6/TzH1AMXWoTfI0VRDChAwSBiEMrwCi0xi+HuDKKiyJ9b+naNTL6PLSME15 KmyJbxOVvmEiRNrOOFze/ajupmlwckT6hzXVHsq/fEbLBJeXN9F8oP/VuU29KMGqGey/ mqPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730411588; x=1731016388; h=content-transfer-encoding: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=F27qB7pqs4B+H6rgwMgg110YnYCYCyECaYMkJQesej4=; b=N8xCzXiyTdEiDEMm7yP3JSqx1GBcZwOqwcVsc/PiB8NJoC5E2mnoRrhPojFYem90w5 yaqHhqDSaeb0kBa76/T32eUJMqmAd4W608MTFHHeK60UaVhqPm0DZQlmVAV53c75ifeW IVFzZ9R8wdTCfvQn2sK5OCKTq+nGH105qrcInbMOyiMS18Td2X/OkPKU2ujuZezbuo95 GrAg2TETWeSd/9J9ZjRXEHdSEuuUw3ioy4v6j2NWRPXmXeAjTXH7VnKCbClO9wGZoLyf 0J4qFWEeBF6krhWjawipDCKCjZMSpD2QfrCbYgzcSunpmile1y7E45x+DQpfk9JNEADQ Njtw== X-Forwarded-Encrypted: i=1; AJvYcCUhgdBIs8+XGnSqvmssADCYr5UKU756ZWircGGlTHBiHr1LZniVtzRToAZ/5uh5A4fQSLx+dT2zKg==@kvack.org X-Gm-Message-State: AOJu0YzvbkMOsQWvewCuF0XcR6aOODGSh9Z24g4IB4LlNfL5ua9JEagc 2rl9oCco9I7YDaazzmkAK+iLcVAXDJYPeZHJ+7RkMWTHeQYaio8Nvmonm6EzYFIub2A9vvaBq4A vfwBWeRZyJUrTIKESLlnL2fhma60= X-Google-Smtp-Source: AGHT+IHqMc8D1fTcJBHC56Bby5MV6Wwd0AQM0m6uLJ3UMWC4kMsq8PIQR4kUOKsExi9cp8mFoCadMXsDzzN7l83LUiw= X-Received: by 2002:a05:6902:2b0a:b0:e29:6571:b107 with SMTP id 3f1490d57ef6-e33025b5d7emr1532044276.32.1730411588315; Thu, 31 Oct 2024 14:53:08 -0700 (PDT) MIME-Version: 1.0 References: <023c4bab-0eb6-45c5-9a42-d8fda0abec02@fastmail.fm> <4hwdxhdxgjyxgxutzggny4isnb45jxtump7j7tzzv6paaqg2lr@55sguz7y4hu7> In-Reply-To: From: Joanne Koong Date: Thu, 31 Oct 2024 14:52:57 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Shakeel Butt Cc: Bernd Schubert , Jingbo Xu , Miklos Szeredi , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@meta.com, Vlastimil Babka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 387B21C0002 X-Stat-Signature: cisumcdzhuwy4u1mtinheyio56t4613t X-HE-Tag: 1730411577-272979 X-HE-Meta: U2FsdGVkX1+vGsGGHoHhNUbxOSRrYJG17d5h4k0cagFaeObXWmuwa8RSG17xcfVyf/5oJvLjCBzB2e+otxbJ2R9XYYLog5022LYRNDguVcuVzWucXvApXmwCzx/oZ+3gJmzi/OvfQNIp3oFgGb96Hp9HYyOKkJU8K/92WzI/sPtOYC8VY/2tPwb3f9xChT5126j/63KLJvBcBf7SF7nTfp8vtn2J6jLjSsv8L08qkq4ETXxEqqBM3S3COzslFxEFTvWU1rP9929rcdSfRAtalnfUhmRr85hm0GZhECEWA8mYFakjujynMBt3uVa7BwJC7QNXdDSpG7gfUswkXi9YedkEjnOI74gXp8cWt/CkzqTUp7p1QmOcYoHPnmkZJMsz6uWWTZmqix+QqhFd8XvEn9P/RvytJu6dnRYpXIIwG5OWFDPNllds3QVWwnug4wlVUglDGTJE1WosV2X6x8F0+yGWeqchUnTXUfLswtbK8wKmjqrheVvngHgGQSt7jfzgCZMHgZsqHmEenStT1mnebOeMRY2BsF69MuNtkGepWUw89qyh+oE/hCkewZ4CSNR96IHgHvGtoYDWqyJrSgRTh4xgjb8890xLsFAJZB0Mua3kQqElq23J3F9URPNkXHfz+Kb9GKsscn20GJkGNXKouLn/TV7anyPCZLIOvMJnCeA6lGH/yEBQmWqtBsMxexKrBzq8rCfmC37ErQNzZ8u/3sQ9PnzQXCeXH82TrknqFpG9RV6XaKIjV0jvnZr/MW1rTbrElHAnyqIbWquXsUoxYO8pASugi1qGUSQW7w2k4QGkP2/8spWqtrUAnTk9akgOwHTuHAspkeZQtICk/zo0sYkzu3k4a1x5cm7houKLmN0WzDeq3HqdpCCIQ+e6CmoO+SbuK/aR7CHop39eYhm2CxrnWjJriD0VhkYuo4y+ays0PruxvrRmzSSqfFfLcK/1UOBWIJtC+HAB5+DQQMH j80dnZIU 5QI08pJj950VVGSE+MMQw9cmc07E5i4XRlgmW0/d072tO7IzUvv/YC0EVRt42KXv9ENEe9XjGcxgkc7m/NZw/dLQBFyQtFHOaOGLmrNDjx3xGbQnbKQU4LtEw7MVX77g80Kc6xX0UtBo3LO1CStYFuAj1+1aEI+KplHRaijBMUyCPnDUOgEEO1YEMOUkv7BWWfhm1R8CsaYatDvdoqIbvZ4Wi0n0IflgMUc7zE/Zjo6ZwWYHaGNy9PxQBn73Hffd0TnX0AnGk5XiojXBb63xLT2M93ybsp0FTXCImqqC5OQQp384SqGi2ZNk4Jmg6kz1ooa+X X-Bogosity: Ham, tests=bogofilter, spamicity=0.000038, 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 31, 2024 at 1:06=E2=80=AFPM Shakeel Butt wrote: > > On Thu, Oct 31, 2024 at 12:06:49PM GMT, Joanne Koong wrote: > > On Wed, Oct 30, 2024 at 5:30=E2=80=AFPM Shakeel Butt wrote: > [...] > > > > > > Memory pool is a bit confusing term here. Most probably you are askin= g > > > about the migrate type of the page block from which tmp page is > > > allocated from. In a normal system, tmp page would be allocated from = page > > > block with MIGRATE_UNMOVABLE migrate type while the page cache page, = it > > > depends on what gfp flag was used for its allocation. What does fuse = fs > > > use? GFP_HIGHUSER_MOVABLE or something else? Under low memory situati= on > > > allocations can get mixed up with different migrate types. > > > > > > > I believe it's GFP_HIGHUSER_MOVABLE for the page cache pages since > > fuse doesn't set any additional gfp masks on the inode mapping. > > > > Could we just allocate the fuse writeback pages with GFP_HIGHUSER > > instead of GFP_HIGHUSER_MOVABLE? That would be in fuse_write_begin() > > where we pass in the gfp mask to __filemap_get_folio(). I think this > > would give us the same behavior memory-wise as what the tmp pages > > currently do, > > I don't think it would be the same behavior. From what I understand the > liftime of the tmp page is from the start of the writeback till the ack > from the fuse server that writeback is done. While the lifetime of the > page of the page cache can be arbitrarily large. We should just make it > unmovable for its lifetime. I think it is fine to make the page > unmovable during the writeback. We should not try to optimize for the > bad or buggy behavior of fuse server. > > Regarding the avoidance of wait on writeback for fuse folios, I think we > can handle the migration similar to how you are handling reclaim and in > addition we can add a WARN() in folio_wait_writeback() if the kernel ever > sees a fuse folio in that function. Awesome, this is what I'm planning to do in v3 to address migration then: 1) in migrate_folio_unmap(), only call "folio_wait_writeback(src);" if src->mapping does not have the AS_NO_WRITEBACK_WAIT bit set on it (eg fuse folios will have that AS_NO_WRITEBACK_WAIT bit set) 2) in the fuse filesystem's implementation of the mapping->a_ops->migrate_folio callback, return -EAGAIN if the folio is under writeback. Does this sound good? Thanks, Joanne