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 6EEC6D767FB for ; Thu, 31 Oct 2024 20:06:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74E9E6B0082; Thu, 31 Oct 2024 16:06:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FCFD6B0083; Thu, 31 Oct 2024 16:06:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EB8F6B0085; Thu, 31 Oct 2024 16:06:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 418536B0082 for ; Thu, 31 Oct 2024 16:06:55 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B6C7F1C7601 for ; Thu, 31 Oct 2024 20:06:54 +0000 (UTC) X-FDA: 82734979404.01.0CC4DE1 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf26.hostedemail.com (Postfix) with ESMTP id 234C514002B for ; Thu, 31 Oct 2024 20:06:29 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=T+1tP24o; spf=pass (imf26.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.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=1730405079; 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=/3piDMTe1Kk4AU/igSSQtPB4+xpblPFIYxIyz1dyWvI=; b=Nyq2iVwbXaj3sSOZr/ocr9wJ+/vBxsqgEqc/fq57FDDleRsFpuVaCmkcwDFsxiQ4rSLHZh MUsApKnBNxW9TSu9/ELwi7BdAoa4JIU8UfEvNCsxvSjBOMLdcL+P9g6N0aDmYu93FRiSVE Jjb9wmbow/VEf65fOJGHGOad2lDhWlA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730405079; a=rsa-sha256; cv=none; b=vfntuaP4yPv/ZiQc2y5JTr5LdGwiklWc4nCAnxm+6hcmBnaTZWlaCnl2MuYn/m9fsRcsvz qhFXXAHoyINSxlAGfrvqYqp7tl6ifj/SFjBDKNxo55FOkDUFJ8/ARqWXmfmlHaAan5THPj tTMgYGJ54gkRMiPYlEicK58SDDZtPEE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=T+1tP24o; spf=pass (imf26.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 31 Oct 2024 13:06:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1730405208; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/3piDMTe1Kk4AU/igSSQtPB4+xpblPFIYxIyz1dyWvI=; b=T+1tP24oQEx0lYJwh8asvqHHD7CJAWJxtU/lIN3BRw2a2NNmTEgeTEWYIHLFKdGuAY7eFr 2HNS4bD5SOrL5n8pmwz9EUxrnl6tR6cjMEg8oTEsIRPS3SRQFe7kpowy+TEhLXZdV1+Z9E worvHcF1Vz1omdEvc8aKnEQ1Hyzv5ko= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Joanne Koong 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 Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree Message-ID: References: <023c4bab-0eb6-45c5-9a42-d8fda0abec02@fastmail.fm> <4hwdxhdxgjyxgxutzggny4isnb45jxtump7j7tzzv6paaqg2lr@55sguz7y4hu7> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 234C514002B X-Stat-Signature: 93kru4rstz9cgp8qn5mdbek97ha1mf93 X-HE-Tag: 1730405189-235875 X-HE-Meta: U2FsdGVkX1/VsGl//UEyPrtKnKjKJ+zJTXmwjUiTkQIfFvV/9KPnoq38pG1s63MtnRLeaQfGzSh7mw1l97Y+aSeCTtsRJJQXdpQQN6NzIh/WewRjZEqr4V7N5C/1nK2v7JZsNCerdDzovn4cN1zaeYzklgy1tLBmQptdge7Tx/G2kFtsTIBhNSaDM9ATqrTrQy6NlahMrZjQCgL8AiYJAUApDrLsxJudSiwLGOjMNzxpdYrS4xdiNeHa9YXSYzLcC0ZS/WQzTOfriqbxJyzDiz4ExVdIJggIDVbI1I+/I7gsq0uO/FzU4gbAtRQi4EfKtvi2a1JoqGdqUgH+3yO3UoGAbe/L/vHdwgDz2AvialGKS4Sz2azKrT7WfAVI8ImUEo0dOm3E5cQr0stSdjrASL1frVp6MmDDsAGJwb+QeSpKsouJKJM45pWSeZNfDorv9aTFOL5DSC64mwvDE2fyEY1X9AhbvFSm/kz47pjoKmqr4MkKR49oWneksOKLs3f761cj/dh77d9BmkJNWeUvtt4mnvcpZA3tQPNb1UQxpPUPdkcLAP755kpnHu8ZNpWHoW9rLRT1RdZ/LHByzyS0dI5CsnwAPUUV6Jgv7QcS/cE509vBvKmXeiSMeBtOCqZz0ipJBXfNM9WbSyPvAT/Y1lCawyN6Fk5/EbxDPLlPe7U1rWd4trZOYLiRwodSHaqxhdONSNmjg6OPrqqjNQ9L0Cx/QvQOB3DY8faZTBpjQ5XRxxwbTu94QgOUDm7HabT+vUIMkAgOEJlmksiIS5HdP+ZriA8VaQcJ8JwK4ZY6oqB2O1uPznG5Q5Tk3VeHVouAlhc8upoHVPGBNIjh1fzgl3dbDLLs8ut2oTWfnaQo7X2IeMzFCSsYZWCWDYXCTNo1wHUr/4m4oG9pFBo1s+hR7LsunwoU5AefEGTjxz0Fz73jUCIEj8KiGH06JbENIKPjDA/rY1Folg/eDPNreKh HsgMMmtn nBKo7tv1voNs4MUywWTW/8ldrMgGPpNL9wbTYqq7D+7uldy0onoh8UXChCXPdNEaHPGSA6LLVtQqWgRmbAI/lFNhmzA4u2ENST42wPRLRRPaBSgAla0rMeFgXPBlvFoPL9NaCtuqQ3KD4gsTxDU8CNfySU6Uc8wuRqtvRwV697M8Y09U= 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 31, 2024 at 12:06:49PM GMT, Joanne Koong wrote: > On Wed, Oct 30, 2024 at 5:30 PM Shakeel Butt wrote: [...] > > > > Memory pool is a bit confusing term here. Most probably you are asking > > 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 situation > > 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.