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 E75DDC36002 for ; Mon, 24 Mar 2025 15:02:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB89C280002; Mon, 24 Mar 2025 11:02:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B688C280001; Mon, 24 Mar 2025 11:02:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3255280002; Mon, 24 Mar 2025 11:02:57 -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 85931280001 for ; Mon, 24 Mar 2025 11:02:57 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C155455DCC for ; Mon, 24 Mar 2025 15:02:58 +0000 (UTC) X-FDA: 83256762036.06.70ABD9C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id D943A40006 for ; Mon, 24 Mar 2025 15:02:51 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FBUtQeBP; dmarc=none; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742828574; a=rsa-sha256; cv=none; b=CVuRiAB2mWsjVdCn3zr0jS7hy6oIqduSGPBu4q2awkHhx9h7hNWPbwE1uF2pcqsZ/lIemh mcp10cZccKI6o8FlSxoo/QFKolFnfQBG4ygF8SBjY2bAHf+dECR37ZgM8uw9QuXCEKT6Ow e7mLO4XoUotU94QWhxUuynIGM04kXDs= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FBUtQeBP; dmarc=none; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742828574; 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=35uXtVKGaER37nteavlftmrAz1omkXbLtRVHdTRcrGg=; b=X7W/f/fGbGTzmiMa4KcXOu8btIrvZneRrEIqtr/n7KAAzyUd47LWCG6z9GYdwk+mwMAYIl F5Hj5AcRounSri+0s8alfWZ1Ec5vXRM+g8crStjTKsTfa7yD8a+J6zeQPm/I/O51t93gDP 7UUJ8c+K3z/uRo71bH3xDzEyd16kSf8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=35uXtVKGaER37nteavlftmrAz1omkXbLtRVHdTRcrGg=; b=FBUtQeBPskXqJVfpcbX/bRxJvQ U2UCMFZYdpfbptLlHKjGYxLU2B8/oQDhAPnh21t9yzMuEVHHDwfI1ONuI6/zAc0hjPr1f7m1TZtZO e2dBaQR4jEQWGFfU+py5gItU6l5FA0x5kChkEyVut1rJ9GQXTwqjj/3UsuDEMZyQIdEioE301qkJA HTV1KguSRIZ0g9ni6Lw5xaadMh2gnEAIsmQknuozj4ZbDD08+uHfbDcSY3Y5DFFVBtrG3sBRLvxMH 8FDNI2L8lziT8Qzs2L6EqViVNqEq99VAOspCmx48yoD+PJtOba1BhHVs5tnsdSeddHaa5CsiS3EY3 Z8eGSKnA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1twjJu-00000000odr-3Z0q; Mon, 24 Mar 2025 15:02:30 +0000 Date: Mon, 24 Mar 2025 15:02:30 +0000 From: Matthew Wilcox To: Bart Van Assche Cc: Luis Chamberlain , leon@kernel.org, hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, axboe@kernel.dk, joro@8bytes.org, brauner@kernel.org, hare@suse.de, david@fromorbit.com, djwong@kernel.org, john.g.garry@oracle.com, ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com, kernel@pankajraghav.com Subject: Re: [RFC 2/4] blkdev: lift BLK_MAX_BLOCK_SIZE to page cache limit Message-ID: References: <20250320111328.2841690-1-mcgrof@kernel.org> <20250320111328.2841690-3-mcgrof@kernel.org> <5459e3e0-656c-4d94-82c7-3880608f9ac8@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: D943A40006 X-Stat-Signature: cwhjruyjdu667q8kznipeextrm9kp6tj X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1742828571-883440 X-HE-Meta: U2FsdGVkX19PZuQ4qZkULdh6tfFv/6ZIHuXcV6eCt4l36VLmsjf7TWDwvjsEOL72qvMjVgariXqxsnm4bnLv00nSqVsE4doK777e/v8qZqKksgzY9jNCqd9XntF8hih6UEsxIeQsXVGuCbqUKqtXN/SiQf2IyzqNBTMckdHFZSEPq1ej8oAqhMmiSKSeam7FS0CiXLLS4ixnE1516fAAIIkirlD1Sl+LNr00jDaaVnHxucdH/JIFJC4+B9Z+gtJ6IM6M5mylmCcvLyddFcAj3rVqkCa6Yvx+irN0kyp1OGtAVEZY3rdzBsGfWIDx2ZEbqARMNLGraUOIDmScMIcx9tSlOMSzwJWOVqmv4cQHl8pQCZUXGhDbdu00w6bUAJctUHGZcOlDmWUoA9zrSWt8bzMFsdWCnJh6CMBcIw1vRMnVne21MTkczDEnRRe5pFfSiSjnm0Ck712eC72+bKxvOKZSOjp6fGACglH+LVGjHnyJBHB5T/MnoAHX7lAVpejIcQcEr73sDj3oUXMrYVqMKROrDgnp9zBS3xn9MUC1/Njdx0vVyIgbcbdFAjrswh/2dvYzYLfF3u9NCmPvJ8yUJTYbJbcmcAU/fWk8xnAQ29wiLZZoNLo03aD9Q0OhcUAy4qHX3N/SiUHaXT53pxt2zpaBDxdQ4oO4WOqLq6NYGh872t8Cz3CZ2XuLI5Q8goPEPNoCrp21Zl2j8f7dJvjD23Px2YdLQnYxGiH/hXZR3hyQV22MoAqmB+UPkxKB9lL6O4IdZTWvMoFmIaWsAcX2rxH0qSKc1LdKg9iRA7/gYny1L7tikhL4tFGISYcRRlW2i+hzaa2P7r+QhRc99cz8NtUoNGIgOUyRixww8iHS202XEan9lruKJtrMMhnPJ1XU5xcA6dcndqNQ3/53Vgmtn7Azbj7unxwd8B8c20SvXPQv3m3Qjzo8txl5rkXdUKLqNNMIKDkqhdy8BqO3rxe XfA93BYb YQcQL00ryuOz7GWIjcSoYh0pV/hQ2WqJor7s0b0EvifdPtft+Q/27h3A7vJL4U1k/CxGDwzcO14Xi9MQGFlq4+5hFF5aRVitLd94Ek+TCd94msq8IbRbsOz3vsIEr72yuk8GdinfeUSW3VR3xINNRAlpx+JJezHRAp16BOrwZ6W/mPpqhv8RMGTDGgs/40fUxJgvYgHh067Rib1UPPwRBKCyHUBBWFu6QJPudLkI8uKgsrcVjd2jovdJsoz7sU4heDjnV9B3iv/MZXJ3ICUN9EXuaKOncUOFHcnhh2uTAoxFsRdZ8cY6fxnEubTqDDvP8UiZsOjKYE1ZC4gtb4npCrPRi8Vj3iYmgmcvn X-Bogosity: Ham, tests=bogofilter, spamicity=0.001137, 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 Mon, Mar 24, 2025 at 06:58:26AM -0400, Bart Van Assche wrote: > If the goal is to reduce DRAM costs then I recommend SSD manufacturers > to implement zoned storage (ZNS) instead of only increasing the logical > block size. A big advantage of zoned storage is that the DRAM cost is > reduced significantly even if the block size is not increased. > > Are there any applications that benefit from a block size larger than > 64 KiB? If not, why to increase BLK_MAX_BLOCK_SIZE further? Do you agree > that this question should be answered in the patch description? Do I agree that we should use the commit message to enter into a philosophical debate about whether ZNS or large block sizes are better? No, I do not. I don't even think we should have this discussion any more on this mailing list; I think everyone is aware that both alternatives exist. You don't like it, and that's your prerogative. But at some point you have to stop being an awkward cuss about it. I think CXL is an abomination; I've made this point often enough that everybody is aware of it. I don't make it any more. All I do is NACK the inclusion of patches that are only for the benefit of CXL until CXL has actually demonstrated its utility.