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 97991C36002 for ; Mon, 24 Mar 2025 10:58:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB5B9280002; Mon, 24 Mar 2025 06:58:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E646B280001; Mon, 24 Mar 2025 06:58:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2E02280002; Mon, 24 Mar 2025 06:58:51 -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 B6872280001 for ; Mon, 24 Mar 2025 06:58:51 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4EB481A18D3 for ; Mon, 24 Mar 2025 10:58:51 +0000 (UTC) X-FDA: 83256146862.04.E1EE01F Received: from 003.mia.mailroute.net (003.mia.mailroute.net [199.89.3.6]) by imf12.hostedemail.com (Postfix) with ESMTP id 5B3E840003 for ; Mon, 24 Mar 2025 10:58:49 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=acm.org header.s=mr01 header.b=weSd2VmF; spf=pass (imf12.hostedemail.com: domain of bvanassche@acm.org designates 199.89.3.6 as permitted sender) smtp.mailfrom=bvanassche@acm.org; dmarc=pass (policy=reject) header.from=acm.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742813929; 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=qHWnXl7QzKO/pXeMQIokr+0rghD0nnpt18hbCu3fEWw=; b=WWw6HylTSUBmI6NLIRdDgfFztBj214ZjsE/Hct0KgkU2Szc33jM0PQU9rnX24Afnhnwdry Ji3a9Ov2vdX88uGgxOYbMadGLq215rX7CFoRwIKEuiIVTDpY5BMCXt6Pu4ZoM9jlQZqLke D1OPQlcBZ3Y0x7LkMbIhBDdgm7RHY7s= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=acm.org header.s=mr01 header.b=weSd2VmF; spf=pass (imf12.hostedemail.com: domain of bvanassche@acm.org designates 199.89.3.6 as permitted sender) smtp.mailfrom=bvanassche@acm.org; dmarc=pass (policy=reject) header.from=acm.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742813929; a=rsa-sha256; cv=none; b=2Rm4ceK9r42FK2E8ABP82k4JJ/S4kvmB6EvRbGIgH36qoEDyV5uTcw9Khw8SL6XCSfs4ke 4mtJxwi3LMAI6AGLiSleAPTjCkoMAaoHJi0N4S8TmAIOKtGqGBrC1hQuDyVReyNIMxRVSn Xr3VddHNY1zEfEd3HkG2HYS6FJGXjYM= Received: from localhost (localhost [127.0.0.1]) by 003.mia.mailroute.net (Postfix) with ESMTP id 4ZLqmS1qwtzm0R3r; Mon, 24 Mar 2025 10:58:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject :user-agent:mime-version:date:date:message-id:received:received; s=mr01; t=1742813925; x=1745405926; bh=qHWnXl7QzKO/pXeMQIokr+0r ghD0nnpt18hbCu3fEWw=; b=weSd2VmF2OMTqgTjsbIuZtT/MRyOanBpLKlCYj7Y RECtUB+Sy5QO2wOxdv3LKADHEGtWXwKh9BgTTcIdEPWpmq1hnjgaVYglOlMuEiHM rglZrP3CiALvb8X6xbDD5JP79/PEJy+FJBe48GnZD1OUviyCzJS/PZ/mM+njGDZN wyGOu5/MXIoVAJq6CwUoMhcnSDqKaJikeS6tIDLrSoYyH/LXYvx1voganLX+kicj s1HLfdYTI0f/Ad0TTSbExUfHlxa2hYLVK96RxJFZfAezOkLM9777is2jiVjJu0Aj leJOwJNiSqlPs8lOTj4CEj2fZ7SgWdv6wBvYk/OjbipFyw== X-Virus-Scanned: by MailRoute Received: from 003.mia.mailroute.net ([127.0.0.1]) by localhost (003.mia [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id fx8_Kpnf0S6p; Mon, 24 Mar 2025 10:58:45 +0000 (UTC) Received: from [172.22.32.156] (unknown [99.209.85.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bvanassche@acm.org) by 003.mia.mailroute.net (Postfix) with ESMTPSA id 4ZLqm46VPpzm8kw7; Mon, 24 Mar 2025 10:58:27 +0000 (UTC) Message-ID: Date: Mon, 24 Mar 2025 06:58:26 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 2/4] blkdev: lift BLK_MAX_BLOCK_SIZE to page cache limit To: Matthew Wilcox 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 References: <20250320111328.2841690-1-mcgrof@kernel.org> <20250320111328.2841690-3-mcgrof@kernel.org> <5459e3e0-656c-4d94-82c7-3880608f9ac8@acm.org> Content-Language: en-US From: Bart Van Assche In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5B3E840003 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 16mico1dtt9qkmtpop5u84frwj96cfbm X-HE-Tag: 1742813929-412884 X-HE-Meta: U2FsdGVkX198CtzNZCGFt8l71IT1H+E6OiEieciWpXlN8rtaO1FHWiNU5v9OcyoRqCmnEJoQeg4F4gDsdD5AYjFFN7cN521LR7X6ocWcouUeLwOB8+r+XBhir+JBLVjVScZcBj7dgsn4D1cnhkR2WZpYzGNdjMmO0S5nBl6BRq5kxqH2TIqRNdFijxbzwbR0nZk8cAPEQzLVBSpzSp71xypIjs0IZr2+Hf2aempj7WuafN1/hOoy9hHgNwfl2x3U6d/UCMP0I+MLI//35v+xIbT3CUwzGtckl8o/IOBUKtggCjKNA9n1aAC9byGrMN2el8UgGUgl2HzTFVkJYykbzA8NHVCXz+s8ZZvZxXabHY+sZRyC/rnFgqnhUl0L8JzdhVBDldSOgZsWpTQUtL1jDdgC8UI3I/PSqQrNWMJFubBLoau0HgBdq0PuXMOifnr7M2USajfsZJYfGWl+zlEnP6ynoNTTnDdt1Mwn++Ecb3ZdEh2KvSJnqe4/E8FkYDdQiZD63+L8qo2Inr3MlTZbmHI8/GnxTwwju8kCOIIGSGPVGa/1A0ToQWts23qfzevHCHYnXYbd9QQQsKIPmFdIo3Fzu00iJuqYNMQN8kjG+x9xzKCD5Gebsn3vuVj0SAwyhBtjZ6m9OMgMMvE8fG+AHcddmXDdNW4jUmhV1xJDJJRjO/uLkYvEp9BS2GF6ZI4OCiz8mS/vDrQbBYzFMWy8co5u0dOZESiOpDz7MK4DJY5C0RTxi9Ar/GaV5qFeqO7fp76eJo92vcBYIi++6EZOp0VlmGdvZCfjdAj3NqqR/QKIeZkfDBLjW50c9qpmnYaelr7WiSdFKArELIf8mNpXTj6IUYYAcmlztYoiV9OJFwRyezTJeRCRZr9q82REcAB+qEK7zSm6IZhg6vp8paHpjqEI17RzF5eKDWgdUcMCcXAI4IN2qZoDwut3y/7aEH04JUO5ixHNq40m4sejYnr eaclLgHY jS3gLIF8EDBNmHxfHv5Wa0B1L3QIgSnt8wOEy5iB2HinwF+vbYu3pNy+8JvBI4TvomGLRrsssTGz8/ETxebjE/KY179SaQpq6WYdPHB4cjXIl/ZHHzturPwx5XnA7+Nx0U5ObSvHCyiOr2iBAreBBXZY9SlyMFFff6+7EiHJBRaTLbZA1uwkBuvAnYD9ZW5hGSTSszfGi4Lmp5wL1/ByP3ph0q5H4FITK94PeOxpyFY40MDqACtXB5V0Odg8hQ8Ha3zv7oAsF3IBf6qlKpHuIQYFCeMoMsKUpVcSVCxUfMNeev8IhfBW7Ku+f/peTl2ZFazX/GiYtMLwX98wFgT1yr/B2zrhZDaYbbaeYh6XN8zumGAqSzHeAOOxJQ1bCTg6UuIWDt0BuChKc2eUGR9uf3HXPqqKAPSPe0hQ0jWyUUfyAFixlvr1lknnu6I05q5CmZ4qfg0MGwwqJEfQz6l+/bxu5QHpqeW+yD8NYxgTrgoUmiXk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.008118, 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 3/20/25 12:27 PM, Matthew Wilcox wrote: > On Thu, Mar 20, 2025 at 09:15:23AM -0700, Bart Van Assche wrote: >> The patch description mentions what has been changed but does not >> mention why. Shouldn't the description of this patch explain why this >> change has been made? Shouldn't the description of this patch explain >> for which applications this change is useful? > > The manufacturer chooses the block size. If they've made a bad decision, > their device will presumably not sell well. We don't need to justify > their decision in the commit message. From a 2023 presentation by Luis (https://lpc.events/event/17/contributions/1508/attachments/1298/2608/LBS_LPC2023.pdf): - SSD manufacturers want to increase the indirection unit (IU) size. - Increasing the IU size reduces SSD DRAM costs. - LBS is not suitable for all workloads because smaller IOs with LBS can cause write amplification (WAF) due to read modify writes. - Some database software benefits of a 16 KiB logical block size. 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? Thanks, Bart.