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 45A8CC61DB2 for ; Mon, 9 Jun 2025 04:35:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D58C76B00A5; Mon, 9 Jun 2025 00:35:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D2F906B00A6; Mon, 9 Jun 2025 00:35:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C47476B00A7; Mon, 9 Jun 2025 00:35:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A3FE86B00A5 for ; Mon, 9 Jun 2025 00:35:42 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5775C14044F for ; Mon, 9 Jun 2025 04:35:42 +0000 (UTC) X-FDA: 83534598924.25.713BFA5 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf12.hostedemail.com (Postfix) with ESMTP id 0C95E4000A for ; Mon, 9 Jun 2025 04:35:38 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=rHP7I9UU; spf=none (imf12.hostedemail.com: domain of BATV+8c169eee6154a7585371+7960+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+8c169eee6154a7585371+7960+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749443740; 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=oeT73a0Hi9cOPyGYRSLUMdSjrVNXI7sw9Uk+bmyEzn8=; b=hms0fYrNWsg5dgRx7P3UJZ+065l5LyAtAhhzgyZ9akfcCmocHkIWh0oSW+OfbDfnDXLLzp xxoui8MGmXeUhjgWV9OuaxKfn6caS7rYELOdPJanBkTPMKGLojWDT8u5C94Mdo1MN72mj8 gGC7oj5Awf5Uu4dSDcqiRA637Q11buk= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=rHP7I9UU; spf=none (imf12.hostedemail.com: domain of BATV+8c169eee6154a7585371+7960+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+8c169eee6154a7585371+7960+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749443740; a=rsa-sha256; cv=none; b=WZwbbLeU2cOG8Lj1ch6yF6oXoohY+Marsw2Jadyk3rdKt7MkPKN4rP4qmQtwA2XumDl3BQ NQs8/WqohtSLc9qE2LmxLPLk4cEN7iNiLmGCEKrUNcq4IPmO7qSen8kquqzvMrWFWxNo4h Y1wnaV4/K0gnumHD6WMaCcpLoZX3Gp8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=oeT73a0Hi9cOPyGYRSLUMdSjrVNXI7sw9Uk+bmyEzn8=; b=rHP7I9UUuAQAw0byw2iIpo1lFJ zvbVPtfIVNEnDvZ9E1i3kI/uUWfH3Lg4IFfJamPPveKy03Ptn8AT5+IuiPsJ7Gyj1eLYvV75kkky/ KwEenybj6HmEa1IyjFVizqFwSAnml8QPm1xdo5gomYU6y2sIPE3yqFTe86Dt5WnAL4OmASNCKIv+1 NlmPjRydtMGYf+nz6hNKwgJbXio3bde8bWS1ewqdobg5JeCyxqwY3UhWGBuSBlgamJ98mC3IyE4eX gvBIUrrc3DfdJkX6pLBCFDhVX3Fftro4JvRfYYVf73aJ8wi9Jo0li4WYB/42oSfqwWDkVP2Xm571M rMrSru6w==; Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uOUEG-00000003PoK-2Bfw; Mon, 09 Jun 2025 04:35:24 +0000 Date: Sun, 8 Jun 2025 21:35:24 -0700 From: Christoph Hellwig To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: wangtao , Christoph Hellwig , "sumit.semwal@linaro.org" , "kraxel@redhat.com" , "vivek.kasireddy@intel.com" , "viro@zeniv.linux.org.uk" , "brauner@kernel.org" , "hughd@google.com" , "akpm@linux-foundation.org" , "amir73il@gmail.com" , "benjamin.gaignard@collabora.com" , "Brian.Starkey@arm.com" , "jstultz@google.com" , "tjmercier@google.com" , "jack@suse.cz" , "baolin.wang@linux.alibaba.com" , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "wangbintian(BintianWang)" , yipengxiang , liulu 00013167 , hanfeng 00012985 Subject: Re: [PATCH v4 0/4] Implement dmabuf direct I/O via copy_file_range Message-ID: References: <20250603095245.17478-1-tao.wangtao@honor.com> <09c8fb7c-a337-4813-9f44-3a538c4ee8b1@amd.com> <5d36abace6bf492aadd847f0fabc38be@honor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Stat-Signature: kuj9fne3mbecauci86adjow4zgtn8mwi X-Rspamd-Queue-Id: 0C95E4000A X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1749443738-577825 X-HE-Meta: U2FsdGVkX181folBYXNWqBasoCGQHz2zHDpke7jAeqXOnFxrCkdQOwsjrxk4mVI7j/6lVAzd9cY+RQ9bu8EJ2XmE4yt378IFzebAVWYh37NJu1TwrSocuy+wcUv+1ll/qgCAzA5SYO3gmWwI16BIQzTV02CzoGmy4BoTtG/ptWusQ2n8xQFTkBQqkmCHHKpqW8aRyBdsQbMlf+9WtO4XHZlOhVFyU7wYRqWgirQixswQ3hAS+A0RuttqeyfcfmNTmCD6zszArrfASsl2QY3e32pd0WHXVT1UjVGcBRZ8vyi1uO22vtWn8MgmyCJxNnsPZdbdAqtoJf+C6j11obJPUEJzDpinXAcu7yyk7LswrVbF1N/sUvL8YxwafQ0EHVYuGcdNH4AiRzd7KkaNi3KTSKoB3Z3NeNRIOuxvoW5NSNyVw4uRJ0kr7Gn9jZfA8l6DEVY23Cm3UqsRb5x/VQ5ltvy3crrswctpAX6WP4i/KnWKuo+UisAb8Y9wNg6PJZO7qoY9fzWSD5KCITGlUoXhETbC0c0pleTWQz3asmu40ZJyzPRaxGrXGKJF/+JNDpMh945WdQVLv6FuzIvxW0aAH6/sT4mjWCIlhb/ozC4BXkQL9Y0Qrqu2ZxSYpLxYmSCQDt3lADdQfKR/4zQgSH9bzqJ6j00tkcGEi+ClrZsDU7k1dneNE2Px4goyKNerekBoh50X2gSbycnO7JGOTcYH+I93PjxEr+t5vKEL2LA9KU0YTmQeu6jjZe9C46/+cIqoqievQlswmLXvw/1oU6NUcraZNz0eKo0G1T3mbMk1qmTEyWICt8JciYy0oIT2+VG9fuhorfZoQ9Q0mQfE9rl8ayyU9VU7wHvDAIZQL3Yre5KLnE33DMK/tEvLlqbT/hBvSXG2f1encJ04WNTgJlKf98EKBZKTmYxFDeJ0Mk/dQxZj5iARVaqo68sCe6K6syPk77E3DlJxYnBXL/422fm e0bELv+v Q6zf3nXPfyx4Z2B7trul5JlXZopGwpEFF0gYLeV5vEqdbqFUMeM8yamko3DStwc7I++ZUJKlz7FuED6lC+yaxb4YL1Gy1YZqp2vCW8DKqi6bZzwJevu1xta/8Xp/+HD9q5gSgeApvB9onNUgj/iFWLbPKrHzKga0GnEmuZ3tMU03jkclC6zOJNCW+1mnGhal9kOlSsqlL7m+gSWiFFMIZQn0UAz+nnLAONe369hB8CzUTlPZhARRGBvDSZ5qtsm52K/RvZtuHH129cVuftPnMouFeU/LroTFfxW/7inXbAOP80mR807FOEiTP+q/cYvS3gSiXPUfj7E+lszbb4fQ6VM4AxfQNyrw9Rrv2q4h7sgkVf1c9mx4Yu/Q0MCBgjraQY4rXb2pxKZGfiWGngWd1oJfhDTOhKzlezP/KiGcaipdyMMDVmjgspMalxLkrRdRvK+Jz3VWbTfulXWmpzZzwyM/VHeQ9Y2+9H1bvEN4jzMFjhrEKFjaJ9OmLsphFuMXmy4ApSL4p1Jtx08aQ7lodAZVievcgaU4oBuc7l1A3ZcjyxjTjeC5X2jMDHAViNto2L9HrpSVBroCoVLFxxNa2g0RSDA== 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 Fri, Jun 06, 2025 at 01:20:48PM +0200, Christian König wrote: > > dmabuf acts as a driver and shouldn't be handled by VFS, so I made > > dmabuf implement copy_file_range callbacks to support direct I/O > > zero-copy. I'm open to both approaches. What's the preference of > > VFS experts? > > That would probably be illegal. Using the sg_table in the DMA-buf > implementation turned out to be a mistake. Two thing here that should not be directly conflated. Using the sg_table was a huge mistake, and we should try to move dmabuf to switch that to a pure dma_addr_t/len array now that the new DMA API supporting that has been merged. Is there any chance the dma-buf maintainers could start to kick this off? I'm of course happy to assist. But that notwithstanding, dma-buf is THE buffer sharing mechanism in the kernel, and we should promote it instead of reinventing it badly. And there is a use case for having a fully DMA mapped buffer in the block layer and I/O path, especially on systems with an IOMMU. So having an iov_iter backed by a dma-buf would be extremely helpful. That's mostly lib/iov_iter.c code, not VFS, though. > The question Christoph raised was rather why is your CPU so slow > that walking the page tables has a significant overhead compared to > the actual I/O? Yes, that's really puzzling and should be addressed first.