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 0437DD609A1 for ; Wed, 27 Nov 2024 06:26:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 830BE6B008C; Wed, 27 Nov 2024 01:26:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E0596B0092; Wed, 27 Nov 2024 01:26:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A80E6B0093; Wed, 27 Nov 2024 01:26:13 -0500 (EST) 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 4DECC6B008C for ; Wed, 27 Nov 2024 01:26:13 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 00C5414063F for ; Wed, 27 Nov 2024 06:26:12 +0000 (UTC) X-FDA: 82830889806.17.7776C82 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf16.hostedemail.com (Postfix) with ESMTP id 4662918000D for ; Wed, 27 Nov 2024 06:26:05 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=gSmtkFMG; spf=none (imf16.hostedemail.com: domain of BATV+3febbf1faf3529cf413a+7766+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+3febbf1faf3529cf413a+7766+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=1732688767; 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=svFKMDnIpssns1GfQO/ozEz62VHItFor5LMbPjt5/PU=; b=MAvPVme9T8gJHiwNj1nrizNZ8O9D5nm8C7u6GoYgTmlsRmKYqd8vx06JDW+yeUgxswaC/S sVKg9v81PTgYVURh0pNc/x77Fc/sjz/YbWLHXRQdEsRzN6HL5uXWHz983LhGuMawfw4hd7 NCzO7/LGyXRLV1B3I46W7qs/Y645cek= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=gSmtkFMG; spf=none (imf16.hostedemail.com: domain of BATV+3febbf1faf3529cf413a+7766+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+3febbf1faf3529cf413a+7766+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732688767; a=rsa-sha256; cv=none; b=DS1OFW+Ib3QtF0qadQIE6B1nLCDSeKzZvqTNdIz7EPv7IA8UNScze13m3K3E29Ra9pW+xi SM885A9TBBJp1XLYI/MaO5u7kUouaSPhEjV9oWa473LaDXwDPTxEH1FiF8CHKBDy+e7vt8 G1r4cLqeJhixy2pzh5/Ft9ZTdATf0Zk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=svFKMDnIpssns1GfQO/ozEz62VHItFor5LMbPjt5/PU=; b=gSmtkFMG3LekA1oRJCL/pMlRR/ blHE5zUXFIXc3dUe3ILhknUcfniIcelNCziYoQoAmdbxXIgy9rbJNhjWs1ZzCVIq9cpdg+doj7GgS 8aqEnuKZaOi9gntZjKDnXJzYHw4LG+96EM+ZxgpcIV3NOdtErehV9RRsHIHq11LC2NePj2XNwysUO QRSBnXhhPn3CX/HChXPHVAyacVX732l1bQFLq7LsXk191V/RN6qqzUyNrH6tPMxVJo3pt5eTO++ym bbKouJRaC5D93wFFB4ctKOHSyXofEK/rwrRbN1ei8359ZAF8LIQ5aQduW1N7ZY+HzlnKx39xAp8CP 8G0TUrsA==; Received: from hch by bombadil.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tGBV1-0000000CKH0-27tB; Wed, 27 Nov 2024 06:26:07 +0000 Date: Tue, 26 Nov 2024 22:26:07 -0800 From: Christoph Hellwig To: Bharata B Rao Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, nikunj@amd.com, willy@infradead.org, vbabka@suse.cz, david@redhat.com, akpm@linux-foundation.org, yuzhao@google.com, mjguzik@gmail.com, axboe@kernel.dk, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, joshdon@google.com, clm@meta.com Subject: Re: [RFC PATCH 1/1] block/ioctl: Add an ioctl to enable large folios for block buffered IO path Message-ID: References: <20241127054737.33351-1-bharata@amd.com> <20241127054737.33351-2-bharata@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241127054737.33351-2-bharata@amd.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Server: rspam05 X-Stat-Signature: wysnzt7f8uyeac3o85itbapqkfctyuhc X-Rspamd-Queue-Id: 4662918000D X-Rspam-User: X-HE-Tag: 1732688765-207024 X-HE-Meta: U2FsdGVkX19TF6D/wRQv+fp2GY8cRUTn7mD+kA4UlD0+JltHPxI1gBAd+KGu3eNRKlKHQAnNpQQoNQm7h9vl3o50BcEPVA/Hmn94nxRf7U09gmlUVnnMxkmt0r+omfi2UnXHtD0p01JIA2owo/pWbuwb0725SU7KtkRdKre9rKuPTYVX+ukZwkreAPgC2E36EqpTzRcom5SOY1gGiKunbyjF04CZeAyOGu1LRLXN3pdFmrpgTUMdPaWWNoE1MMoN6BAql55fro1vQL0uPq4dmbuK9+boKGqZlibH0zSmL3igIUadOyiorEtoNZckB9QpHU7CXJzAHiLEN7gisYkC3e9r3APyGMHleLLPbtfBgtbBtk8bOEbYn9BmghQPV4acZsdf88zeJ0jjBgccZH5UyMr6iLFUGFRiXITH0mME+gO0CZ3R0x4f2amLdHl15zI72Uw3GcSfsSsEn375+1f0X4S/VHHa8PZeB3bslxO5Bzw57tKwDE74omvG08ezK2/y1UpzjzoYfMFonVKWVYULmcmcNcqSxLJb1X2f1tfW+Yq8YduUSRFgDrp9QoWbiiKm3tJIDLRTd1c3AePDqiXCc5ruuUDc2XaNUR7qQCeYuw4RnbCnYj5/P3uraksaoXY+toC11FFNB1LjraG+YAC64oeK+E5Fwc7YPI/IUffqLExHtOo/iPucjrQdzHP0bAh16BRZpQXGDqN+4fnWizSZJN4erQ2GPSYZKg0Anh7siLAF1Zz0zJsxF3N8BqR66Fbla/EnwV8xOarVkJiuvR/PmO0WI4XlnD5y4XPgae0z4lS4J/c9cUNFfk7xVV0bwswvLgFVj6rhlqeE1ti4n/C2RTayWz9Q9WW9I5Ak7bifGaOD0cbib/PMUBBXiFBEztb0kf5VFrRecdIISv8z94UY4D9sbjOSICQayOskM703hzdDUMe0xqZWapd2R0hgrCpbTkTPfvlOLa18Bv7d/oa Cl6iDxxm uS0RhAhkx4Uyl2BEn380mfjEzaQVNGY86Omwg82pA49d1USzAadFsYqLRcnq8h0qHoaAG/98Z7nBEveqa6v309QNyzqoZ4wYIuGYRKYDf62STR3cHb/YULpJF9L2LwqmlPzA+uoH1GoHrK+/OzdtDn53v9hpBsImz4+KA4pBbRUOkP0EfgruKmvOVtzgpGojhHDSUHXp5jtUk35gDurIm7aIm6Wj9w9fstrTndc9G6G5nAl358bHPiCmP+j85poxkL2CGPEKQhyH4YidYoslr0ss8s/tJPlOxSbY28R9yVxiAQB4yly+ygPbxhcaYR6y9JvWG0PelIuPYorP4+W9fA1G5iexngUcOXGjagg7LrBd9RCtwiPTJdIvoKjLXhP4DqVCZhYKjallFLga9BFcqnAgvmUawsOCpmpumaQL1jQhnYIKL0qePkcazy2x6zodXk6Gyo17c8536ll3V4VQ0qDNlL8Qjm7oaIO4gPpC7dNhI5f8= 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 Wed, Nov 27, 2024 at 11:17:37AM +0530, Bharata B Rao wrote: > In order to experiment using large folios for block devices read/write > operations, expose an ioctl that userspace can selectively use on the > raw block devices. > > For the write path, this forces iomap layer to provision large > folios (via iomap_file_buffered_write()). Well, unless CONFIG_BUFFER_HEAD is disabled, the block device uses the buffer head based write path, which currently doesn't fully support large folios (although there is series out to do so on fsdevel right now), so I don't think this will fully work. But the more important problem, and the reason why we don't use the non-buffer_head path by default is that the block device mapping is reused by a lot of file systems, which are not aware of large folios, and will get utterly confused. So if we want to do anything smart on the block device mapping, we'll have to ensure we're back to state compatible with these file systems before calling into their mount code, and stick to the old code while file systems are mounted. Of course the real question is: why do you care about buffered I/O performance on the block device node?