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 0CE94E77188 for ; Tue, 14 Jan 2025 21:40:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8239F280003; Tue, 14 Jan 2025 16:40:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D2C6280002; Tue, 14 Jan 2025 16:40:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64CBE280003; Tue, 14 Jan 2025 16:40:16 -0500 (EST) 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 41CDA280002 for ; Tue, 14 Jan 2025 16:40:16 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DC20A140589 for ; Tue, 14 Jan 2025 21:40:15 +0000 (UTC) X-FDA: 83007375990.30.CF831BC Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) by imf11.hostedemail.com (Postfix) with ESMTP id D387A40010 for ; Tue, 14 Jan 2025 21:40:13 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=fastmail.fm header.s=fm2 header.b=sIGjZFgn; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="w 8Co961"; spf=pass (imf11.hostedemail.com: domain of bernd.schubert@fastmail.fm designates 103.168.172.145 as permitted sender) smtp.mailfrom=bernd.schubert@fastmail.fm; dmarc=pass (policy=none) header.from=fastmail.fm ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736890813; 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=7SnkAapVOWOoQzhpCp9f1lx43PiwZJ468hSDGpsT83E=; b=NY6pMUrbwU/E40E9FqYJV6DZJ4aIOStRKUq3+TsWDaf4/8h7/Fc91BrthFXSmrCC6A5zHn sVR/meetKDJsvzgHqri+CfpOvrqorpQWDPbDQF6I1Bbl6+jsfdY+l6cykza4DVztDL1sJC JSbCCktbco6eiihlUob6e8Gw+d9YDrY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736890813; a=rsa-sha256; cv=none; b=vHG/JjI2F5aFCT2e7hfWG1RH9FkPbtQaUAYuf9glb4jvLRKaoXWqR+YlvIcyoh3ztgpi5p x9s0kXxc6NOH8dhYIroqbzRFIJaP/HlM0NY0j7w+eDvqSuLAuRSjEb5Q6r1rxCfs3SHOPM 6e+73SvQITZu1ZQbuS97ylar3DHcFyQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=fastmail.fm header.s=fm2 header.b=sIGjZFgn; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="w 8Co961"; spf=pass (imf11.hostedemail.com: domain of bernd.schubert@fastmail.fm designates 103.168.172.145 as permitted sender) smtp.mailfrom=bernd.schubert@fastmail.fm; dmarc=pass (policy=none) header.from=fastmail.fm Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id 3E2A8138025D; Tue, 14 Jan 2025 16:40:13 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Tue, 14 Jan 2025 16:40:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1736890813; x=1736977213; bh=7SnkAapVOWOoQzhpCp9f1lx43PiwZJ468hSDGpsT83E=; b= sIGjZFgnPlbWPVIYQM4v9OpVA3MPqqTkbsuLQL7BiNLEk9v80DTBpT7unrsbGcDs uoys8thnagm+NQlm19aaSii75U1jZTOPtKbLwTtmHlMQ9IneZVFdwIaAdqTD4vvG H1SaheEp2sP/OqBdJL8zlP51EQikHeGWjzpIRx04XF4qBs2O1UvdG/HnyHZzLkZW xPc4qXiyl4gZtrHJEefYfy2KnuT8YBJZr5XxCUbmOtMnvA1GVlAiTimsDU0rQces kZkHkt0DosiMw7X19+pgNmdFmECwi076gS4VoygZPNz45w6xzbf3CPaJEU3xP11y E5mTuy8XUM55FkzPQbZXww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1736890813; x= 1736977213; bh=7SnkAapVOWOoQzhpCp9f1lx43PiwZJ468hSDGpsT83E=; b=w 8Co961eEsl+3e08D50sQEQci5sLOC7pW59FVCXV0rXs/lTT7Es7NDAFW2KYttCle WPp8VpwNeIrlQIqpoBwVq7WPbnae7A6mYCZsXXAgaz+SSis2pIQOBQqSrCJiq6lG XB9qgV10VpLAndY7Q4/HgxP266Zmto0C9dmOu8Lj9/UGeGce4W4p3LL9GvS0pKjW lqFhWSpk/MHj2RDJaYdFrlkEV98oBxni4GWi+lhRUgpmqw85XTwstfRbjgV2FMHC Bu22mAenjbY6+CstuCVVt4otN8WXP44Es270Wv+r0uuzFvF0pEY256KV/swP5k1c HdcIyoeYP9B1y3EhwY2QQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudehiedgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddv jeenucfhrhhomhepuegvrhhnugcuufgthhhusggvrhhtuceosggvrhhnugdrshgthhhusg gvrhhtsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeevgfeukedtfeeu gfekueeikeeileejheffjeehleduieefteeufefhteeuhefhfeenucffohhmrghinhepkh gvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepsggvrhhnugdrshgthhhusggvrhhtsehfrghsthhmrghilhdrfhhmpdhnsg gprhgtphhtthhopedukedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhlrgih thhonheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepjhhorghnnhgvlhhkohhonhhgse hgmhgrihhlrdgtohhmpdhrtghpthhtohepmhhikhhlohhssehsiigvrhgvughirdhhuhdp rhgtphhtthhopegurghvihgusehrvgguhhgrthdrtghomhdprhgtphhtthhopehshhgrkh gvvghlrdgsuhhttheslhhinhhugidruggvvhdprhgtphhtthhopeiiihihsehnvhhiughi rgdrtghomhdprhgtphhtthhopehlihhnuhigqdhfshguvghvvghlsehvghgvrhdrkhgvrh hnvghlrdhorhhgpdhrtghpthhtohepjhgvfhhflhgvgihusehlihhnuhigrdgrlhhisggr sggrrdgtohhmpdhrtghpthhtohepjhhoshgvfhesthhogihitghprghnuggrrdgtohhm X-ME-Proxy: Feedback-ID: id8a24192:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Jan 2025 16:40:09 -0500 (EST) Message-ID: <630dd043-6094-482a-9544-f4eb4202d1c2@fastmail.fm> Date: Tue, 14 Jan 2025 22:40:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Jeff Layton , Joanne Koong , Miklos Szeredi Cc: David Hildenbrand , Shakeel Butt , Zi Yan , linux-fsdevel@vger.kernel.org, jefflexu@linux.alibaba.com, josef@toxicpanda.com, linux-mm@kvack.org, kernel-team@meta.com, Matthew Wilcox , Oscar Salvador , Michal Hocko , David Wei , Ming Lei , Pavel Begunkov , Jens Axboe References: <1fdc9d50-584c-45f4-9acd-3041d0b4b804@redhat.com> <54ebdef4205781d3351e4a38e5551046482dbba0.camel@kernel.org> <2848b566-3cae-4e89-916c-241508054402@redhat.com> <060f4540-6790-4fe2-a4a5-f65693058ebf@fastmail.fm> From: Bernd Schubert Content-Language: en-US, de-DE, fr In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D387A40010 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: c3dinxazbo5uidkqwij9bki4zu7w4u1j X-HE-Tag: 1736890813-879015 X-HE-Meta: U2FsdGVkX1+ngjTvbTcX1gYJ6zaaBV34o7eNY9+Fwz7HUNVQz/re9NhVhfKluyt3fH8hcm8oTsAG2rreAL2V8zugi773D0GLlJEYRpyYZecIQzvKfXvNCwxEBFmJKwhmmQqLMJxeCqRdZHCgznwtvjOTQPaWqUAQ+dncRegiErpaUlTyqCy6kDd0HIQykkbMvheI/G/WMWDar2VUVDTNHHxXsUZeYdSiTP9USpN7gwHkL1GoKmVx3ykLeqyPI0I8F+rxrdzGg8AmrC6XFVHZjCeqbfzwqZpXcHkDZBx8T3tnV16L+Ns/+b8QupUfeTYSUW14eJrSSkQ1rq1MaFHTD1Sfl2MAjrdQQ6tk6A+cckyU+2RPq03tD6SjYcnv1Quo8xIitEi6EbbLTFtSB3bsQOyh90F45zEJAjYcKUPqLLYJMp0xOt1yNjbqVSzZ1m0R2wp7k6UO+/CoLaStDNGnGJ2g/JzRKkwarEH2X3nOiqZXwG6rhLlAqppzuN6MSp7uxMocn0uaEZT9o9JWjGY2iy8oUWlwd79sRgfEnVo1CWQC4/yHwv1Mv6ePpgRoswknO6jU58tTnPck+xuhluXKfMvsxGnq/jjZluH6omkpaMctHcjWk/owFkijWzVJ1xh3fcWS29GIt14RcTIw47biw8zfdCQNbXuqo4bMJG4KlC8s8TEo5XlY2XXKDwRNtuD26aja3wKVwiT+WhbCCM7k8cZtg5PyilMJWbKWVPfVRC3RohqITEyVmvbj0Hk4wwaXnVx9HBxtuzdJnnBvYCB1L2rTXueC2IAPxb3vcXP7zvCEz+sef1vrkkTKPNm3oBwzXxVS/tUsNZqaGiRsAcEs9SXOcAy/zpshwKEFervjx+KrbtyCFxsUBxZaKyA9ZkZHZBAZLaOWhzNisTUu5Sxs14U06L4ok4azQV0V36UQSIm4Ewzsdo/WXMvwduYpP6WPhsgBeenI2O6ugNv3Yfs mRXc/TBY X0MLRdTYyfAmdmmhYD4CBpldZdhxnWLld1/uOTcH6G5anbORprYQtrzZbuA3eNs0D0miJ55zVBh3hPd1MFRV36NcqVil8xTm2OPEFeBAWpMFiVcWm1Fws1G2ehYjxzZfvPpaPdPpbAakPMWbypULQ4KPZwNV/yITNAixSclx+OL+62Z9eQEZrzqyUSnUR82bQiqj53q/5cP0o/MGxw/s87K5pauvrUDjwgH/ibH2S2BRmer3rXYKdtasd6w+4ZGlbWvsFnNNmHJgtOws2DhWEMTA0yvuiBwHFFMWnoLpHq6OkZLkE07bKRtfbYyEpH7qt7BRQq3KtAeJgMvEbHY6l3ODefSRmch6CNbMPZahZdLe+ju7logJIuIX7MUPKWixiej5H8RjIBvOX7gcqsTyAI/iveNHePTHXS5k8xss8nr9X00HpR0puFgjGJ7Cjkpw/H7+or+HRugui64rQYNDq3VklHjy4dN6FPwbAQ2eSou2Q9DrpV6PooytF4VaR6sQ5wYRR32IsWnf1oE++mEx07P83obb62o6UowaO 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 1/14/25 21:29, Jeff Layton wrote: > On Tue, 2025-01-14 at 11:12 -0800, Joanne Koong wrote: >> On Tue, Jan 14, 2025 at 10:58 AM Miklos Szeredi wrote: >>> >>> On Tue, 14 Jan 2025 at 19:08, Joanne Koong wrote: >>> >>>> - my understanding is that the majority of use cases do use splice (eg >>>> iirc, libfuse does as well), in which case there's no point to this >>>> patchset then >>> >>> If it turns out that non-splice writes are more performant, then >>> libfuse can be fixed to use non-splice by default. It's not as clear >>> cut though, since write through (which is also the default in libfuse, >>> AFAIK) should not be affected by all this, since that never used tmp >>> pages. >> >> My thinking was that spliced writes without tmp pages would be >> fastest, then non-splice writes w/out tmp pages and spliced writes w/ >> would be roughly the same. But i'd need to benchmark and verify this >> assumption. >> > > A somewhat related question: is Bernd's io_uring patchset susceptible > to the same problem as splice() in this situation? IOW, does the kernel > inline pagecache pages into the io_uring buffers? Right now it does a full copy, similar as non-splice /dev/fuse read/write. I.e. it doesn't have zero copy either yet. > > If it doesn't have the same issue, then maybe we should think about > using that to make a clean behavior break. Gate large folios and not > using bounce pages behind io_uring. > > That would mean dealing with multiple IO paths, but that might still be > simpler than trying to deal with multiple folio sizes in the writeback > rbtree tracking. My personal thinking regarding ZC was to hook into Mings work, I didn't into deep details but from interface point of view it sounded nice, like - Application write - fuse-client/kernel request/CQEs with write attempts - fuse server prepares group SQE, group leader prepares the write buffer, other group members are consumers using their buffer part for the final destination - release of leader buffer when other group members are done Though, Pavel and Jens have concerns and have a different suggestion and at least the example Pavel gave looks like splice https://lore.kernel.org/all/f3a83b6a-c4b9-4933-998d-ebd1d09e3405@gmail.com/ I think David is looking into a different ZC solution, but I don't have details on that. Maybe fuse-io-uring and ublk splice approach should be another LSFMM topic. Thanks, Bernd