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 19F9EC28B30 for ; Thu, 20 Mar 2025 16:45:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BCF25280003; Thu, 20 Mar 2025 12:44:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B583A280001; Thu, 20 Mar 2025 12:44:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F8E6280003; Thu, 20 Mar 2025 12:44:59 -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 804D1280001 for ; Thu, 20 Mar 2025 12:44:59 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 07AD058E85 for ; Thu, 20 Mar 2025 16:45:00 +0000 (UTC) X-FDA: 83242503960.23.E015FE9 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf14.hostedemail.com (Postfix) with ESMTP id 4B85F100002 for ; Thu, 20 Mar 2025 16:44:58 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf14.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742489098; a=rsa-sha256; cv=none; b=uNBL91XulebraEhn0hDoStDWTMX/sSMsoCrAbNsp4gmw0YaXDT1HO+mqZfDrTTE9xGwIOh gmDgLekBrv90Jpb0XXyvTzipt4ckRA7dQaOgWW2K/xpdh6kzVLW72CsVnL72+5jyCdTgBY IENobJhgQ+sWYZyse9rHISPJrlIkAP8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf14.hostedemail.com: domain of hch@lst.de designates 213.95.11.211 as permitted sender) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742489098; 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; bh=2TsgK4EgAsLjdnoKtRwklGytSfUPP2DiqhV8GG5infw=; b=E6VlPEacqHHDqY0bgGxOgRg90uB3sf/+nmalHIspOioJolkyea6yDQjhKsEBBM1KEpzgyX 0/0nsaBBH/4NueUoOi0jUWWSGxLGb95In3cCyxla38BiqZ0kJaAxCQjHqSoIzqJ5jdA6A7 SI9kCISziyq53TLFwVKaO6I3/8p1Guw= Received: by verein.lst.de (Postfix, from userid 2407) id 271EE68AA6; Thu, 20 Mar 2025 17:44:52 +0100 (CET) Date: Thu, 20 Mar 2025 17:44:51 +0100 From: Christoph Hellwig To: Bart Van Assche Cc: Matthew Wilcox , 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: <20250320164451.GA21364@lst.de> References: <20250320111328.2841690-1-mcgrof@kernel.org> <20250320111328.2841690-3-mcgrof@kernel.org> <5459e3e0-656c-4d94-82c7-3880608f9ac8@acm.org> <7cc6f537-aac4-4bfc-80f0-1829a850d56a@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7cc6f537-aac4-4bfc-80f0-1829a850d56a@acm.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Server: rspam07 X-Rspam-User: X-Stat-Signature: aud1fpqzx713yww551aqc1o1wp1emo76 X-Rspamd-Queue-Id: 4B85F100002 X-HE-Tag: 1742489098-651052 X-HE-Meta: U2FsdGVkX1/ZjaSNVFKMvTbLSqxwxUbsfIO4j2c0WYELaaecOm9mgulfar9soW6iDQ7GX/t4Y5nDSTeAHmyTJCFFp5ejZgzfBPvJJYuJLt5MkRycL8HVsbN0dsCKTns8uNk8slka2WYxtb2GmdmRDti0zJhzAoDQzoX/twJWauhB7E88WsfIvZyS3dAUibdZuKbUgHT8l1auF47oFNC3ge8gdEraocsmOd87CxOOQbMwZlWR1j9BDG3Tiy8ILKJ3KR2ZTUukDB0cNyoznfdvOgX7HFluO/FO+Ct4rL2EPkCuOIaMQ9AEaG8dx0fCu7b46lx2aQEHLm9QPezyY7NybJTFWQsLaaoGWfJOZWjsXuyXpRHgbEMxZeaPnb8iejJGm3U2hzIraShyrtOOITiibiFdMxr82ipCmz3IPzTXLAbyrXbk2oVYHhVCJj8X7ALzA+RjTipQS+ueejYMe23FM7n7Cr15ljhJengdz6UumU5w9Rs63Wg6zC6tYhVNzhy+SLC1U/8z2YYFM1lkMIYRCctgp3CLRJF5avBaJFeYarVmpWTojrN/eRFg+CAjl6c1wGj6t6L4EaCLXf6aSWtBi7by0dwkYGteKF+GqO4IkVFlodyg6gK9voH3sp/U+c7v309ORPVfvTt5j6avH7JyaD4dmhuepucU/3oSy5dDiItcwlrrV90DRExURQUOoCgz3gT/Oo+idn8uzXdQAL8mQn3eTkdSuFRlzLyFN0HiGB1ioden3ZOy9LsfK7mTUF64FMyqtgayA/3sxgUwhG2CM63bHSa7S7H8a6J00kvFQvcnqZNq6g2DQccF+AYweyp4uSs1XjynmxJ8qwFQseeV6EHGOKEiwn7Nbaa9PJgHqGudk7IbanhTytTjMEtfoKR+4vQCWHAErwb6SqaL7WSj5D3DTQtjAKGVzKyUfJ/81q0OrJxvsVWw2R+3sc5zisfyNe+11MRNkX46ev2DHvn wlYmbKkQ GxsB5DeFGI1n/U2WxFfCk280as6ValrA0Qm4aoJbOk2Q9bO75owmCKXTWPAObj7+xcH29b163BOJqzZtW0zpcsysm47ZeGVPFAJAkuT1a3eA+qurE+TmP8SUs/N7JFGAEZuXPHZqCB9Vpx8os6PyfU6vATz/U/mpxv67qtgxUkdmNm3D2TFtwt3zSckUu1lroL29z 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, Mar 20, 2025 at 09:34:50AM -0700, Bart Van Assche wrote: > The fact that this change is proposed because there are device > manufacturers that want to produce devices with block sizes larger than > 64 KiB would be useful information for the commit message. I think it's just the proposal that is very confused. Keith pointed out that number of segments mostly matters when you have 4k non-contiguous pages and that's where the quoted limit comes from. The LBA size is a lower bound to the folio size in the page cache, so the limit automatically increases with that, although in practice the file system will usually allocate larger folios even with a smaller block size, and I assume most systems (or at least the ones that care about performance) actually use transparent huge pages/folios for anonymous memory as well.